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