On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote: > >LRA only ever generates insns that pass recog. The backend allows this > >define_insn, requiring it to be split (it returns template "#"), but > >then somehow it doesn't match in any split pass? > > Nope. The elimination code will just change one register without > re-recognizing. That's precisely what happens here.
That is a big oversight then. Please file a PR? > >>Register elimination ultimately discovered that (reg 30) was the same as > >>the stack pointer and did the natural substitution. The natural > >>substitution results in invalid RTL and there's really no way to back > >>out and do something different AFAICT in lra-eliminations.cc. > >> > >>The only reason we fault is because the H8 backend knows this is invalid > >>RTL and refuses to split it. If we were to try and re-recognize the > >>insn in question it would fail to recognize after the substitution > >>because the auto-inc'd operand overlaps with the other operand. > >But it *did* recog? Or does LRA somehow not always recog() everything? > >I always thought that was one of the huge improvements over old reload > >(it does everything very locally instead of very globally)! > > No, LRA does not force re-recognition in some cases, particularly for > register eliminations. It is the only way it can know if it needs to reload more. Even if it somehow can assume it doesn't have to check this in some cases, an assert (inside a CHECKING_P) would be nice? Segher
