> 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

Reply via email to