[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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.