> 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
