> On Oct 14, 2022, at 1:10 PM, Jeff Law <jeffreya...@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
