So what was prevailing_mode then?
RVVM2SI, so != word_mode, and basically two glued 32-bit vector regs. We get that from the first call with innermode SI.
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.
yes.
I suppose if you have vector(1) modes your preferred_simd_mode hook should return that, not the too small integer mode?
We disable 64-bit vector modes for this configuration/target because they wouldn't fit the smallest possible vector. I guess the difference is that mode_for_vector only checks targetm.vector_mode_supported_any_target_p (that we have we just always return true) which makes us fall back to BLKmode in vector_type_mode?
So it's not really like we have a vector(1) mode just that it looks like it for mode_for_vector but not for preferred_simd_mode.
But I'm not familiar with all the cross-dependencies here. If that's a riscv port issue we can surely change something.
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).
-- Regards Robin
