On Thu, Jul 2, 2026 at 3:50 AM Oleg Endo <[email protected]> wrote: > > On Mon, 2026-06-29 at 09:46 -0400, Vladimir Makarov wrote: > > On 2/23/26 12:26 AM, Oleg Endo wrote: > > > Hi, > > > > > > In order to move the SH backend over to LRA there is one more missing > > > piece. > > > > > > On SH we have two fp constant load insns "fldi0" and "fldi1". However, > > > they > > > are bound to single-precision fp mode. We were hitting some cases where > > > LRA > > > wants to substitute constant loads, which have been emitted differently > > > originally, and picks up those "fldi0" / "fldi1" insns but doesn't check > > > whether they are valid for the current fp mode. > > > > > > Eventually LRA should be taught to check that any substitution is valid > > > for > > > any mode, not just fp mode. But for now, the quick solution is to add a > > > cannot_substitute_const_equiv_p target hook. > > > > > > Bootsrapped on x86_64. OK to apply? > > > > > > gcc/ChangeLog: > > > PR target/117182 > > > * target.def (cannot_substitute_const_equiv_p): New target hook. > > > * doc/tm.texi.in: Add it. > > > * lra-constraints.cc (get_equiv): Use it. > > > * config/sh/sh.cc (sh_cannot_substitute_const_equiv_p): Override > > > it. > > > * doc/tm.texi: Re-generate. > > > > I spent last Friday solving the problem. I tried several approaches, > > including one used by reload that prevents equiv substitution into > > insns with USE of hard regs although I believe this is too conservative > > and results in missing a lot of optimization opportunities. The code > > implementing these approaches looks worse, is larger, and appears > > artificial. > > > > After some reflection, I came to the conclusion that the proposed approach > > is minimal and targeted: in other words, the best one even though it > > introduces a new hook and I generally prefer to avoid such solutions. > > > > The patch is OK with me. You can commit it to the trunk. Sorry, > > it took so long on my side to approve your fix. > > > > Thanks for looking into it again. I have just committed the patch to > master. However, I'd like to keep PR 117182 open, as the main issue is not > really fixed by this. > > On SH we have more mode-switching things, currently only the fp-precision > one is being utilized. There is another fp-move related mode-switching > thing (fschg) which would be of high interest for folks who are running fp > heavy code on SH4. But I'm afraid adding that will re-surface the problem. > > From a simplistic point of view, to avoid all these issues altogether, LRA > (or anything else) must not blindly replace insns or insn alternatives which > would require a mode change for the new replacement insn/alternative to be > valid. > > Alexandre Oliva suggested in a previous message that this could be done by > validate_change. What do you think about using validate_change in LRA for > this purpose?
Is splitting the instruction patterns a viable way to prevent LRA from using one over the other? Possibly patterns could be made non-recognizable (but we don't re-recog during LRA, just select alternatives?) by making mode-switching add an explicit "mode" operand. I don't know how many patterns would be affected, of course, or how many modes exist. Richard. > > Best regards, > Oleg Endo
