> On Oct 14, 2022, at 10:38 AM, Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
>
> 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.
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.
If reload obeys the constraints in the patterns then the back end machine
definition can be written to avoid the problematic cases, and it is no longer
necessary to have a general (and as I pointed out, overly broad) rule in
generic code.
paul
