Re: [PATCH] Always enable LRA

["Koning, Paul" <Paul.Koning@dell.com>]

> On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> 
> 
> On 10/13/22 17:56, Segher Boessenkool wrote:
>> 
>> h8300 fails during GCC build:
>> /home/segher/src/gcc/libgcc/unwind.inc: In function '_Unwind_SjLj_RaiseException':
>> /home/segher/src/gcc/libgcc/unwind.inc:141:1: error: could not split insn
>>   141 | }
>>       | ^
>> (insn 69 256 327 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [12  S4 A32])
>>         (reg/f:SI 7 sp)) "/home/segher/src/gcc/libgcc/unwind.inc":118:12 19 {*movsi}
>>      (expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
>>         (nil)))
>> during RTL pass: final
>> which looks like a backend bug, I don't see a pattern that could split
>> this (without needing an extra clobber)?
> 
> I'm aware of this -- its invalid RTL:
> 
> Uses of the register outside of an address are not permitted within the
> same insn as a use in an embedded side effect expression because such
> insns behave differently on different machines and hence must be treated
> as ambiguous and disallowed.

I had a bit of a fight with this sort of thing in pdp11, where in fact such operations are executed differently on different machine models.  The solution I picked is to create two sets of machine-specific constraint codes, one for "register N" and the other for "autoinc/dec of any register other than N" and pairing those.  (You can see this in pdp11.md, the mov<mode> definition.)

But the pdp11 case is actually not as restrictive as the rule you mentioned.  The problem case is register N source, autoinc/dec rN destination.  The opposite case, which we see here -- autoinc/dec Rn source, Rn destination -- is just fine.  Perhaps not all that important, but the ISA definition does not object to it.  So I'm not sure why there would be a general rule that says it's considered ambiguous when the target machine architecture says it is not.

	paul