> On Oct 14, 2022, at 4:12 PM, Segher Boessenkool <seg...@kernel.crashing.org>
> wrote:
>
> On Fri, Oct 14, 2022 at 07:58:39PM +0000, Koning, Paul wrote:
>>> 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.
>
> I think that is exactly right for LRA.
>
> Old reload conceptually changed the whole function all at once, starting
> with valid RTL, and ending with strictly valid RTL. LRA works locally,
> one instruction at a time essentially, and makes the changes
> immediately. If when it has finished work on the function offsets have
> changed, it walks over the whole function again, repeat until done.
>
> "Strictly valid" means that the constraints are considered, and the insn
> is only valid if some enabled alternative satisfies all constraints.
>
> I hope I got that all right, I'm not an expert! :-)
Thanks Segher.
As I said earlier, if for some reason this straightforward understanding is not
completely accurate, that can be handled provided it is documented when and why
the exceptions arise, and what methods the target author should use to deal
with these things when they happen.
As a target maintainer not deeply skilled in the GCC common internals, I tend
to trip over these things. With the old reload, and secondary reload in
particular, it always felt to me like the answer was "keep tweaking the
target definition files until the test cases stop breaking". That isn't how it
should be.
Perhaps some of these issues come from out of the ordinary target restrictions.
The autoinc/autodec case we're discussing may be an example of that. The one
I remember in particular was the pdp11 float instructions, where I have 6
registers but only 4 of these can be loaded from or stored to memory. Putting
the other two to work while having spill to memory work right took quite a lot
of iteration.
It may be LRA is better in these areas. I haven't spent much time with that,
other than to create a way to enable its use and observing that (a) I got about
the same test suite numbers either way and (b) the LRA code was not as good in
some of the cases.
paul
