Re: [PATCH] Always enable LRA

["Koning, Paul" <Paul.Koning@dell.com>]

> On Oct 14, 2022, at 1:10 PM, Jeff Law <jeffreyalaw@gmail.com> wrote:
> 
> On 10/14/22 10:37, Koning, Paul wrote:
>> 
>>> ...
>>> But that approach falls down with reload/lra doing substitutions without validating the result.  I guess it might be possible to cobble together something with secondary reloads, but it's way way way down on my todo list.
>> Aren't the constraints enforced?  My experience is that I was getting these bad addressing modes in some test programs, and that the constraints I created to make the requirement explicit cured that.  Maybe I'm expecting too much from constraints, but my (admittedly inexperienced) understanding of them is that they inform reload what sort of things it can construct, and what it cannot.
> 
> It's not really a constraint issue -- the pattern's condition would cause this not to recognize, but LRA doesn't re-recognize the insn.  We might be able to hack something in the constraints to force a reload of the source operand in this case.   Ugly, but a possibility.

I find it hard to cope with constraints that don't constrain.  Minimally it should be clearly documented exactly what cases fail to obey the constraints and what a target writer can do to deal with those failures.

As it stands, I find myself working hard to write MD code that accurately describes the rules of the machine, and for the core machinery to disregard those instructions is painful.

Is there a compelling argument for every case where LRA fails to obey the constraints?  If not, can they just be called bugs and added to the to-be-fixed queue?

	paul