On Fri, Jun 19, 2026 at 6:17 PM Robin Dapp <[email protected]> wrote: > > >> 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.
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? > > -- > Regards > Robin >
