Hi, The status of LRA support for AArch32 is the sequel : - there is some regressions in the testsuite (gcc/g++, libstdc++ and fortran) in ARM mode, all due to the same neon legitimate address issue (tested in hard and softfp mode). - the compiler doesn't bootstrap with LRA enable for thumb (during libgcc build).
As stage 1 will be close soon, my first question is can we add the
code to enable LRA before its ending, and fix the issues during stage
2 (according to Vladimir the legitimate address issue is mainly an LRA
bugfix). The attached patch enables LRA by default but disable it for
Thumb and let the opportunity to force LRA with -mlra, but maybe we
can just turn it off by default.
I need your help for the Thumb issue, as suggested by Vladimir I
disabled secondary reload for thumb (with the attached arm.h.diff
patch) to let LRA deal with it and break a cycle, but I now face an
issue exhibited by the attached testcase (thumb-lra.i) and the command
line:
cc1 -O2 -mthumb -mlra thumb-lra.i
Here LRA as to deal with the thumb1_movhi_insn :
(insn 11 5 14 2 (set (reg:HI 0 r0)
(const_int -1318 [0xfffffffffffffada])) /work/tmp/t2.i:14 206
{*thumb1_movhi_insn}
(nil))
and creates new regs to do it :
11: r0:HI=r114:HI
Inserting insn reload before:
18: r115:SI=0xfffffffffffffada
19: r114:HI=r115:SI#0
REG_EQUAL 0xfffffffffffffada
Choosing alt 6 in insn 18: (0) l (1) mi {*thumb1_movsi_insn}
Creating newreg=116 from oldreg=115, assigning class LO_REGS to r116
18: r116:SI=0xfffffffffffffada
Inserting insn reload after:
20: r115:SI=r116:SI
Creating newreg=117, assigning class LO_REGS to scratch r117
and during this mov processing, we call gen_thumb_movhi_clobber which
ICE because the first rtx parameter is not a strict memory address but
a register, and here I'm not sure of what to do between fixing this in
the backend or in LRA, and how to do it.
Thanks,
Yvan
arm-lra.diff
Description: Binary data
arm.h.diff
Description: Binary data
thumb-lra.i
Description: Binary data
