On Fri, 25 Jul 2025, Robin Dapp wrote:
> > 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.
So what was prevailing_mode then?
> 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}.
But
/* Fall back to using mode_for_vector, mostly in the hope of being
able to use an integer mode. */
if (known_eq (nunits, 0U)
&& !multiple_p (GET_MODE_SIZE (prevailing_mode), nbytes,
&nunits))
return NULL_TREE;
should have made this fail similarly. So I suppose prevailing_mode
had an appropriate size and was not word_mode.
> 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.
I suppose if you have vector(1) modes your preferred_simd_mode
hook should return that, not the too small integer mode?
The reason for the new use of related mode is that we do not want
to commit to a vector type at this point. But I wanted to preserve
an early out here - the vector type computation could be also
completely removed here (and replaced with some other checks, like
for aggregate copies and existing vector types, basically the
early outs for get_related_vectype_for_scalar_type).
Richard.
