On 10/14/22 10:39, Richard Biener wrote:
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.
*If* we went a route to relax the restriction (and I'm still not sure
that's a good idea), we absolutely would have to document the semantics.
jeff
