It's probably changes from the RVV cost modeling behavior, the patches
are of course not supposed to change code generation.
Looks like a proper corner case...
From what I can see the difference to before is that we now always call
get_related_vectype_for_scalar_type
with VOIDmode while we used vinfo's vector_mode before.
In get_related_vectype_for_scalar_type we used to go the
else if (SCALAR_INT_MODE_P (prevailing_mode)
|| !related_vector_mode (prevailing_mode,
inner_mode, nunits).exists (&simd_mode))
route in which we'd fall back to a vector(1) type using mode_for_vector.
Now we go
if (prevailing_mode == VOIDmode)
{
gcc_assert (known_eq (nunits, 0U));
simd_mode = targetm.vectorize.preferred_simd_mode (inner_mode);
where our target hook returns word_mode (32 bit).
Now we fail because (1) simd_mode's size (4) is not a multiple of nbytes (8)
!multiple_p (GET_MODE_SIZE (simd_mode), nbytes, &nunits)
and then cannot find a
!mode_for_vector (inner_mode, nunits).exists (&simd_mode))
with nunits = {0, 0}.
So what could help is an additional pre-check
if (!mode_for_vector (inner_mode, 1).exists (&simd_mode))
What makes this test special is that we don't natively have 64-bit scalar
registers nor 64-bit vector registers (with a potential vector length of 32
bit) but can glue two registers together via LMUL.
I haven't even looked at the code-gen.
--
Regards
Robin
