On 2/18/2026 12:53 PM, Robin Dapp wrote:
Hi,
The mask-mode vec_init and vec_extract expanders assume that we can
create QImode vectors with the same number of units as the mask mode
has. XTheadVector does not have fractional-LMUL modes and we ICE when
trying to expand the actual insns.
An obvioius solution would be to simply disable the autovec expands for
TARGET_XTHEADVECTOR but exactly these optab/mode combination has no fallback
in the common expansion code. That's a known problem and should be fixed
separately in extract_bit_field_1.
For now, though, we do not need to use small modes and can go with full
vectors instead. The excess elements don't matter.
To that end, this patch uses paradoxical subregs on the source (for
vec_extract) and on the destination (for vec_init), leaving the
remaining elements undefined.
In order to obtain the right "full vector" I needed to adjust
get_m1_mode slightly. By default it returns a VLA mode so when
introducing a subreg like above we can have
(subreg:full_vector_mode (reg:small_vls_vector_mode) 0)
where full_vector_mode is a VLA mode and small_vls_vector_mode is a VLS
mode. This won't be a valid subreg so the patch adds a VLS_P
argument to get_m1_mode that returns a full VLS vector mode.
Regtested on rv64gcv_zvl512b. As I didn't have theadvector hardware
available I made the new code paths unconditional (so they are active
for regular RVV) and re-tested.
I'll wait for the CI. Even though it shows false negatives I think
it generally still works.
Regards
Robin
PR target/124147
gcc/ChangeLog:
* config/riscv/autovec.md: Work around fractional-LMUL modes for
TARGET_XTHEADVECTOR.
* config/riscv/riscv-protos.h (get_m1_mode): Export.
* config/riscv/riscv-v.cc (get_m1_mode): Allow to get a VLS m1
vector.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/pr124147.c: New test.
FWIW, we *could* test this on the Pioneer since it has the thead vector
extensions. But I have *no* clue if anyone has really pushed them hard
enough turn them on by default.
I like the fact that the Pioneer currently gives us a baseline test of
rv64gc. If we also have it test rv64gc_xtheadvector, then it's likely
going to impact Shreya (though if they fire back-to-back it may just be
an hour or so of overlap when she starts her day, so probably near the
end of the testsuite run and not burning all 64 cores. Let me ponder
that path.
The patch itself looks fine to me.
jeff
