On 7/21/23 12:55, Vineet Gupta wrote:
Apparently this is a regression in gcc-13, introduced by commit
ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT") and the fix
thus is a partial revert of that change.
Given that it can ICE, we should probably backport it to 13.
FWIW ICE is on an in-flight for-gcc-14 patch, not something in tree
already. And this will merge ahead of that.
I'm fine with backport though.
It's latent on the gcc-13 branch from an ICE standpoint and would
probably stay that way -- triggering would require something to
re-recognize the pattern after register allocation.
I won't object to it going into gcc-13. No strong opinions either way,
happy to go with consensus opinion.
There's also a pmode_reg_or_0_operand, some of those don't appear
protected from FP values. So we might need something like
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index cd5b19457f8..d8ce9223343 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -63,7 +63,7 @@ (define_expand "movmisalign<mode>"
(define_expand "len_mask_gather_load<VNX1_QHSD:mode><VNX1_QHSDI:mode>"
[(match_operand:VNX1_QHSD 0 "register_operand")
- (match_operand 1 "pmode_reg_or_0_operand")
+ (match_operand:P 1 "pmode_reg_or_0_operand")
(match_operand:VNX1_QHSDI 2 "register_operand")
(match_operand 3 "<VNX1_QHSD:gs_extension>")
(match_operand 4 "<VNX1_QHSD:gs_scale>")
a bunch of times, as there's a ton of them? I'm not entirely sure if
that
could manifest as an actual bug, though...
What does 'P' do here ?
It will force the operand to match the P mode iterator, which should be
DImode for rv64 and SImode for rv32. I'm not sure this is wise as I
think it'll end up rejecting (const_int 0) because CONST_INT nodes do
not have a mode.
Jeff
