Richard Sandiford <[email protected]> writes: > "Robin Dapp" <[email protected]> writes: >>> Do you mean that you add OImode patterns? I don't think that should >>> be necessary. Like I say, I think it'd be reasonable for emit_move_insn >>> to split into TImode pieces. >> >> I guess I misunderstood you. My OImode pattern falls back to TImode of >> course. But you suggested to have the generic code split/subreg it >> already, then using the now-required TImode move pattern. >> >> My understanding is that we have the TImode issue (where we cannot split >> a 128b vector into anything smaller) for OImode as well if >> regmode_natural_size == 256b. This is the case if we compile with a >> "base" vector size of 256b (because at zvl256b we enable all VLS modes >> up to 256b). > > Ah, right. > >> Don't we have the same problem then at the 256b boundary? >> (and at every next-larger one once we define an appropriate integer >> mode). > > Yeah, I suppose. Even if those modes are larger than MAX_FIXED_MODE_SIZE, > they're presumably going to be used for something and so at some point > will need to be moved. Not all of those moves are necessarily going > to be generated directly by the target. > > So yeah, maybe the rule really is that you have to define move patterns > for all integer modes smaller than the maximum REGMODE_NATURAL_SIZE.
s/smaller/no bigger than/ > MAX_FIXED_MODE_SIZE doesn't provide the limit that I hoped it might. > > So it sounds like only the gcc.dg/pr44136.c issue remains. > > Richard
