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)))


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.

Jeff