On 10/14/22 11:36, Koning, Paul wrote:
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.
Constraints have a purpose, but as I've noted, they really don't come
into play here. Had LRA tried to see if what it created as a valid
move insn, the backend would have said "nope, that's not valid". That's
a stronger test than checking the constraints. If the insn is not valid
according to its condition, then the constraints simply don't matter.
I'm not aware of a case where constraints are failing to be obeyed and
constraints simply aren't a viable solution here other than to paper
over the problem and hope it doesn't show up elsewhere.
Right now operand 0's constraint is "<" meaning pre-inc operand, operand
1 is "r". How would you define a new constraint for operand 1 that
disallows overlap with operand 0 given that the H8 allows autoinc on any
register operand? You can't look at operand 0 while processing the
constraint for operand 1. Similarly if you try to define a new
constraint for operand0 without looking at operand1.
Hence the h8300_move_ok test in the insn's condition where we can look
at both operands to assess if it's a legitimate insn.
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.
No doubt.
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?
There was in the reload days, though I honestly don't remember what it
was, I'm much less familiar with LRA in this regard, but I trust Vlad's
engineering skills and strongly believe that failing to recognize was
done for a good reason.
It's also worth repeating, we can get the same fundamental failure on
the H8 with reload. The testcase is different, but the core issue is
the same. We have a move with an autoinc destination and the same
register is also used as a source operand incorerctly created by reload.
What's a bit interesting here is the m68k doesn't do any kind of
checking for these scenarios. It just accepts them and generates the
obvious code. I'm more tempted by the minute to do the same on the H8 :-)
Jeff
