"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. 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
