https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #13 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #11)
>
> /exp/ldroot/dodes/INTEST/trunk/gcc/testsuite/gfortran.dg/matmul_6.f90:19:0:
> Error: could not split insn
> (insn 2778 2779 94 (set (reg:SI 3 r3)
> (plus:SI (reg:SI 3 r3 [316])
> (const_int 372 [0x174])))
> /exp/ldroot/dodes/INTEST/trunk/gcc/testsuite/gfortran.dg/matmul_6.f90:20 64
> {*addsi3_compact}
> (nil))
I don't know how this insn could be fixed after register allocation. We need
r3 and a free reg to load the constant. The only last resort option in this
case is to emit something like ...
add #127,r3
add #127,r3
add #118,r3
but I don't think it's a good idea for large constants. Of course we can also
do ...
mov.l r0,@-r15
mov.w .Lconstant,r0
add r0,r3
mov.l @r15+,r0
But maybe it's better to avoid that in the first place. We can allow more
relaxed predicates, like arith_or_int_operand, but the splitter for those has
to run before register allocation (in split1) and we should not allow the "n"
constraint. An "&u" "r" "rI08" alternative would be fine though, since we can
always fix up the I08 case. In fact, I think we should allow such relaxed
predicates for other insns, too, e.g. PR 65317.
I haven't checked again, but if LRA insists on the "n" alternative for
arbitrary constants, maybe it's better to fix this issue in LRA.
