On 10/14/22 10:37, Segher Boessenkool wrote:
Hi!
On Thu, Oct 13, 2022 at 10:47:20PM -0600, Jeff Law 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)?
Really smells like an LRA bug to me.
We have this as we leave IRA:
(insn 10 9 11 2 (set (reg/f:SI 30)
(plus:SI (reg/f:SI 11 fp)
(const_int -4 [0xfffffffffffffffc]))) "j.c":31:7 264
{*addsi}
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 11 fp)
(const_int -4 [0xfffffffffffffffc]))
(nil)))
(insn 11 10 12 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
(reg/f:SI 30)) "j.c":31:7 19 {*movsi}
(expr_list:REG_DEAD (reg/f:SI 30)
(expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil))))
And as we leave LRA:
(note 10 9 11 2 NOTE_INSN_DELETED)
(insn 11 10 13 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
(reg/f:SI 7 sp)) "j.c":31:7 19 {*movsi}
(expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))
LRA only ever generates insns that pass recog. The backend allows this
define_insn, requiring it to be split (it returns template "#"), but
then somehow it doesn't match in any split pass?
Nope. The elimination code will just change one register without
re-recognizing. That's precisely what happens here.
Register elimination ultimately discovered that (reg 30) was the same as
the stack pointer and did the natural substitution. The natural
substitution results in invalid RTL and there's really no way to back
out and do something different AFAICT in lra-eliminations.cc.
The only reason we fault is because the H8 backend knows this is invalid
RTL and refuses to split it. If we were to try and re-recognize the
insn in question it would fail to recognize after the substitution
because the auto-inc'd operand overlaps with the other operand.
But it *did* recog? Or does LRA somehow not always recog() everything?
I always thought that was one of the huge improvements over old reload
(it does everything very locally instead of very globally)!
No, LRA does not force re-recognition in some cases, particularly for
register eliminations.
jeff
