Thanks for your thoughts and comments, Alex! On Tue, 2026-03-10 at 05:33 -0300, Alexandre Oliva wrote: > On Mar 4, 2026, Oleg Endo <[email protected]> wrote: > > > No, there is no explicit state kept outside the insns. > > And there is also nothing explicit that would determine validity. > > For SH, one thing we could conceivably do is to check that the relevant > attributes (fp_mode and fp_set) is the same before and after the > substitution. We don't need global state for that. If it's unchanged, > the transformation is definitely good; if they differ then we'd need > global state to tell, so it would be reasonable to punt at this point.
The fp_mode attribute expresses the mode requirement of an insn and fp_set tells whether the fp_mode setting is being changed by an insn. When LRA (or any other pass for that matter) tries to change an insn/alternative it won't automatically introduce new insns that do an "fp_set", because those are emitted only by mode-switching.cc once at those points where it deems necessary. So I don't think this will work out as you said. > > Unfortunately, the mode switching APIs take a HARD_REG_SET (that SH > ignores; AFAICT only aarch64 uses it), so it would be tricky to check > this with existing generic mode switching APIs. > > We'd need some means to compute all the modes before the transformation, > make the transformation tentatively, recompute all the modes with the > new alternative, and if they changed, revert the change. > Perhaps it doesn't need to compute all the modes. The existing TARGET_MODE_NEEDEDÂ can be re-used as an early check to tell whether an insn has a particular mode setting requirement. If it does, it would trigger detailed validation checks and would also need some new thingy that tells what the current mode is being set to. Theoretically, all passes following the initial mode-switching.cc would need to do this validation for each insn change ... I just recalled, we also have this open PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115948 where that same "wrong fpu mode for fldi1" happens even without LRA. So it looks really like a general issue. It just so happened to get triggered more with LRA. Best regards, Oleg Endo
