On 12/2/25 4:29 AM, Robin Dapp wrote:
Hi,
When we expand
void d() { __riscv_vlseg2e32ff_v_i32mf2x2(&a, &c, b); }
without a destination register we ICE because
use_exact_insn wrongly adds arguments that we don't need and
gcc_assert (opno == insn_data[icode].n_generator_args);
triggers.
Currently we expand a segmented fault-only-first load via use_exact_insn
because its insn pattern wants a Pmode register as source. We can't go
the use_contiguous_load route because that one adds a vector-mode memory
operand.
It doesn't need to be like that, though, and this patch makes the
segmented load similar to the regular FoF load in terms of source
operand. Also the patch only adds additional expansion arguments like
the rounding mode only if the insn needs it and the number of operands is
less than what we need, not unequal.
Regtested on rv64gcv_zvl512b.
Regards
Robin
PR target/122656
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc: Use
use_contiguous_load for vlsegff.
* config/riscv/riscv-vector-builtins.cc
(function_expander::use_exact_insn):
Only add rounding mode operand if insn requires it and number of
arguments is < required.
(function_expander::use_ternop_insn): Ditto.
(function_expander::use_widen_ternop_insn): Ditto.
* config/riscv/vector.md: Use vector-mode source operand.
So I had your first and last two hunks here from an experiment in the
same direction. But I stopped going down that path as I kept getting
expansion failures -- I had identified the lack of an assignment of the
result as "interesting", but didn't realize it was the source of the
ongoing expansion failures.
It seems like a valid (though not particularly useful) scenario though.
You'd get back the updated VL as a visible side effect, but that value
isn't particularly interesting given the way the ISA works. So I'm not
inclined to worry *too* much about that.
OK for the trunk. Thanks for picking it up.
Jeff
