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? Best regards, Oleg Endo
