> On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
>
> On 10/14/22 11:35, Segher Boessenkool wrote:
>> 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?
>
> Sure. But just recognizing (for this particular case) will just move the
> fault from a failure to split to a failure to recognize. From my wanderings
> in the elimination code, I don't see that it has a path that would allow it
> to reasonably handle this case -- ie, if the insn does not recognize, what
> then? Conceptually we need to generate an input-reload but I don't see a
> way to do that in the elimination code. Maybe Vlad knows how it ought to be
> handled.
I probably have too simplistic a view of this, but the way I think of it is
that LRA (and reload) make decisions subject to constraints, and among those
constraints are the ones specified in the MD file patterns. That to me means
that a substitution proposed to be made by the LRA code is subject to those
invariants: it can't do that if the constraints say "no" and must then consider
some other alternative.
paul
