https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #15 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Andreas Krebbel from comment #14) > > So you are suggesting that every strict_low_part after reload can just be > > removed? If that is true, should we not just do exactly that then? > > I think we have 3 options: > (1) Prevent reload from removing SUBREGs in STRICT_LOW_PARTs. > (2) Remove the STRICT_LOW_PART when resolving the inner SUBREG > (3) Define what a (STRICT_LOW_PART (reg:mode x)) means. > > (1) For that, all passes after reload must be able to deal with these > SUBREGs. Since SUBREGs are rare after reload it is hard to say how robust > that handling is right now. On some targets you always have subregs to describe the action of certain machine instructions (like mulh one PowerPC). In the past there were subregs of mem as well. Those shouldn't occur anymore, but most (all?) late passes still know how to handle it. > (2) Here the question to me is which passes after reload currently do > something with the strict-low-part info. Clearly a non-option if we would > loose any optimizations with that. Yes. This potentially even changes semantics, unless we are sure nothing uses the "high part" at all. > (3) E.g. it means that the bits of hardreg x in its hardware mode (the mode > for UNITS_PER_WORD) which are not covered by MODE are not touched by the SET. But say you have (strict_low_part (subreg:HI (reg:SI) 0)) and the hardware is 64-bit. That only means the low 32 bits of the reg aren't clobbered, the high 32 bits are fair game. That does not agree with your proposed semantics.
