> On Jan 12, 2023, at 4:50 AM, Segher Boessenkool <seg...@kernel.crashing.org>
> wrote:
>
> On Wed, Jan 11, 2023 at 05:07:47PM -0500, Paul Koning wrote:
>>> On Jan 11, 2023, at 2:28 PM, Segher Boessenkool
>>> <seg...@kernel.crashing.org> wrote:
>>> I would say your predicates are way too lenient here (general_operand),
>>> but this needs more info. A testcase to reproduce the problem, to
>>> start with :-)
>>
>> I'll try to trim it down.
>>
>> What do you mean "too lenient"? The first input operand (which is supposed
>> to be the same as the output since the instruction set is 2-address) is
>> "general_operand". The destination is "nonimmediate_operand" which fits the
>> constraints applied to it.
>
> I mean general_operand accepts that sp thing you saw. But your
> constraints do not? (I don't know your target well, maybe this isn't
> true). Things like this should be sorted out by reload, but you get
> better code (and fewer problems ;-) ) if you make code that fits
> earlier. The L in LRA means "local": it "just" makes things fit, it
> does not emphasise optimising your code.
The destination is "nonimmediate_operand" which matches what the machine
actually does. It's like VAX and M68k, instruction operands in general can be
registers, memory references, register indirect or memory indirect, memory at
register with offset, or autoinc/autodec off any register.
As far as operand type is concerned, SP is certainly a valid operand for an add
operation, that isn't the problem. The problem is that it's a two operand
machine: the first operand of the add instruction is both source and
destination. And LRA assigned the source register to be the destination
register as required, but then after doing so it replaced the destination (an
FP reference) by a different register (SP reference), violating the constraint
after having satisfied it earlier.
Interesting to know what LRA stands for, I didn't know that.
paul
