Richard Biener <[email protected]> writes:
> On Mon, Jun 22, 2026 at 3:05 PM Robin Dapp <[email protected]> wrote:
>>
>> > So if the OImode pun above fails "gracefully" that very same path could do
>> > this element extraction? So I wonder if some refactoring of cases in
>> > bitfield extraction/subreg simplification could mitigate that,
>> > esp. when those
>> > pesky large integer modes are otherwise involved?
>>
>> The pun is only the fallback when vec-vec and vec-el have failed, so
>> arguably
>> it's already in the right spot.
>>
>> IMHO, the new hunk would fit right before we try vec-vec in
>> extract_bit_field_1, but without gimple, we'd need to ask the target
>> whether a particular mode is a tuple mode or not. Or is there some generic
>> way to know that?
>
> Hum, Richard S. might know.
I suppose the question isn't so much "is this a tuple mode?" but more
"does this vector occupy multiple registers?". REGMODE_NATURAL_SIZE
seems like the right thing to test for that. The problem is that both
AArch64 and RISC-V only define REGMODE_NATURAL_SIZE in the natural way
for variable-length vectors:
/* ??? For now, only do this for variable-width SVE registers.
Doing it for constant-sized registers breaks lower-subreg.cc. */
So I suppose we'd need to fix that first (which would be a good thing,
but a bit of tangent).
Then related_vector_mode could be used to get the associated vector mode.
Thanks,
Richard
