>> vect_array.9 = .MASK_LEN_LOAD_LANES (&c, 32B, { -1, -1, -1, -1 }, _44(D),
>> 4, 0);
>> _48 = BIT_FIELD_REF <vect_array.9[0], 32, 96>;
>> _50 = BIT_FIELD_REF <vect_array.9[1], 32, 96>;
>> f_13 = _48 ^ _50;
>> a = f_13;
>>
>> and _48 as well as _50 spill to memory instead of extracting directly.
>>
>> We end up with
>>
>> (subreg:RVVMF2SI (reg:RVVMF2x2SI 138 [ vect_array.9 ]) 0)
>>
>> which, as we pun the with a large integer mode, involves OImode
>> that we cannot "move". We might be able to work around that in the
>> target in unintuitive ways :) and we could also offer vec_extract for
>> all tuple modes but I figured it could be much easier if expand already
>> handled the tuple -> vector part for us so just a vector extract is left
>> for the target to do.
>
> But the above looks exactly "right"?
Mhm, yes. The subreg itself is not the issue. In extract_bit_field_1 we strip
the subreg, try vector-vector and vector-element extraction and fall back to
subreg punning. Here we pun the source with an OImode (for which we have no
"mov"). We could handle this case in riscv's legitimize_move or accept the
move_multi_words memory spill. I think this only happens when we don't use
partial vectors.
That was the situation until I changed the gather conversion costs recently.
On trunk, we now choose a different vector mode and get VEC_EXTRACT but the
issue is still reproducible with --param=riscv-autovec-mode=RVVMF8QI
-fno-vect-cost-model.
I believe this shows a separate bug in my costing change, which I'll handle
independently.
> What does it generate? I'd exect that same subreg for the tuple -> vector
> part?
When we force the (subreg:RVVMF2SI (reg:RVVMF2x2SI ...)) to a (reg:RVVMF2SI),
extract_bit_field_1 tries vector-element extraction, which we do have for
regular vectors, and succeeds. So the patch was intended to help the target a
little.
--
Regards
Robin
