On 12/22/24 11:51 PM, yunze...@linux.alibaba.com wrote:
From: Yunze Zhu <yunze...@linux.alibaba.com>
Fix a bug th.vsetvli generates from vext_x_v with an imm operand,
which reports illegal operand. This patch fix this by replacing
imm operand with reg operand in th.vsetvli.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc:
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/vext_x_v.c: New test.
I think this was fixed a while back.
The "problem" insns look like this:
(gdb) p debug_rtx (insn)
(insn 39 7 13 (parallel [
(set (reg:SI 66 vl)
(unspec:SI [
(reg:DI 0 zero)
(const_int 32 [0x20])
(const_int 0 [0])
] UNSPEC_VSETVL))
(set (reg:SI 67 vtype)
(unspec:SI [
(const_int 32 [0x20])
(const_int 0 [0])
(const_int 1 [0x1]) repeated x2
] UNSPEC_VSETVL))
]) "j.c":8:18 3722 {vsetvl_discard_resultdi}
(expr_list:REG_UNUSED (reg:SI 66 vl)
(nil)))
Which looks sensible to me. That's going to output "zero" rather than
"0", which is what we want.
As I mentioned, I'm iterating with Jinma on a possible case where
IRA/LRA might be substituting the (const_int 0) form back in. But as it
stands I don't see a need for this patch right now.
If you can reproduce this problem on trunk, certainly let me know and
pass along an updated testcase/args.
Thanks,
Jeff
