> Am 14.10.2022 um 16:40 schrieb Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org>:
>
>
>> On 10/14/22 06:37, Koning, Paul wrote:
>>
>>>> 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.)
>
> I've long suspected the pdp11 was the inspiration for this restriction (I
> have memories of noting it before I relocated to Utah, so circa 1992). The
> key problem is the generic parts of the compiler don't know what the
> semantics ought to be -- so it's not obvious when they do a substitution
> whether or not the substitution of one reg for another is actually valid.
> It's important to remember that sometimes when we substitute one register for
> another, we don't have any contextual information about source vs dest --
> it's a long standing wart that causes problems in other cases as well.
>
> That punts the problem to the backends and the H8 actually tries to deal with
> this restriction. Basically in the movxx pattern conditions, when the
> destination uses an autoinc addressing mode, the pattern's condition will
> check that the source register is different. I would expect other ports
> likely to do something similar.
>
> 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.
>
> And yes, this case where the autoinc is on the destination works consistently
> on the H8 as well. We could consider loosening the restrictions and let this
> through. It's certainly simpler as it's a doc change and removing a bit of
> code on the H8. It sounds like the pdp11 already assumes that case is valid.
But what is the semantics of the RTL IL?
That ought to be documented.
>
> Jeff
>
