On Wed, Nov 22, 2023 at 11:48 PM Kito Cheng <kito.ch...@sifive.com> wrote: > > I am less worry about the thead vector combined with other zv extension, > instead we should reject those combinations at all. > > My reason is thead vector is transitional products, they won't have any > further new products with that longer, also it's not compatible with all > other zv extension in theory, zv extension requires at least zve32x which is > subset of v1p0, and I don't think it's valid to use thead vector as > replacement required extension - it should just introduce another thead > vector extension instead.
The "transitional products" argument is probably enough to add this restriction, so we will add this to the first patch of the series. Further, we'll implement approach 1 (emitting no "th." prefix for instructions in vector.md) with an additional patch on top, which implements the ASM_OUTPUT_OPCODE hook (with a comment that clarifies why "ptr[0] == 'v'" is sufficient there). So the decision about this can be postponed and we can focus on the rest of the patchset as Jeff suggested. Thanks for the inputs! > > > > Jeff Law <jeffreya...@gmail.com> 於 2023年11月23日 週四 06:27 寫道： >> >> >> >> On 11/22/23 07:24, Christoph Müllner wrote: >> > On Wed, Nov 22, 2023 at 2:52 PM 钟居哲 <juzhe.zh...@rivai.ai> wrote: >> >> >> >> I am totally ok to approve theadvector on GCC-14 before stage 3 close >> >> as long as it doesn't touch the current RVV codes too much and binutils >> >> supports theadvector. >> >> >> >> I have provided the draft approach: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637349.html >> >> which turns out doesn't need to change any codes of vector.md. >> >> I strongly suggest follow this draft. I can be actively review >> >> theadvector during stage 3. >> >> And hopefully can help you land theadvector on GCC-14. >> > >> > I see now two approaches: >> > 1) Let GCC emit RVV instructions for XTheadVector for instructions >> > that are in both >> > 2) Use the ASM_OUTPUT_OPCODE hook to output "th." for these instructions >> > >> > No doubt, the ASM_OUTPUT_OPCODE hook approach is better than our >> > format-string approach, but would 1) not be the even better >> > solution? It would also mean, that not a single test case is required >> > for these overlapping instructions (only a few tests that ensure that >> > we don't emit RVV instructions that are not available in >> > XTheadVector). Besides that, letting GCC emit RVV instructions for >> > XTheadVector is a very clever idea, because it fully utilizes the >> > fact that both extensions overlap to a huge degree. >> > >> > The ASM_OUTPUT_OPCODE approach could lead to an issue if we enable >> XTheadVector >> > with any other vector extension, say Zvfoo. In this case the Zvfoo >> > instructions will all be prefixed as well with "th.". I know that it >> > is not likely to run into this problem (such a machine does not exist >> > in real hardware), but it is possible to trigger this issue easily >> > and approach 1) would not have this potential issue. >> I'm not a big fan of the ASM_OUTPUT_OPCODE approach. While it is >> simple, I worry a bit about it from a long term maintenance standpoint. >> As you note we could well end up at some point with an extension that >> has an mnenomic starting with "v" that would blow up. But I certainly >> see the appeal of such a simple test to support thead vector. >> >> Given there are at least 3 approaches that can fix that problem (%^, >> assembler dialect or ASM_OUTPUT_OPCODE), maybe we could set that >> discussion aside in the immediate term and see if there are other issues >> that are potentially more substantial. >> >> >> >> >> -- >> >> >> >> More generally, I think I need to soften my prior statement about >> deferring this to gcc-15. This code was submitted in time for the >> gcc-14 deadline, so it should be evaluated just like we do anything else >> that makes the deadline. There are various criteria we use to evaluate >> if something should get integrated and we should just work through this >> series like we always do and not treat it specially in any way. >> >> >> jeff
