> On Oct 14, 2022, at 5:15 PM, Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
>
> 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.
Easy but cumbersome: define constraints for "register N" (for each N) and
another set for "autoinc on any register other than N". In pdp11, I called
these Z0, Z1... and Za, Zb... respectively. Then the insn gets constraints
that look like "Z0,Z1,Z2..." and "Za, Zb, Zc..." for the two operands. As I
said, see pdp11.md, the mov insn.
paul