RFA: Switch on LRA on ARM (AArch32)

[Richard Biener]

On Mon, Oct 14, 2013 at 4:08 PM, Richard Earnshaw <rearnsha@arm.com> wrote:
> On 14/10/13 08:27, Yvan Roux wrote:
>> 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=
>>
>>
>
> I'd go with defaulting to LRA off until the regression has been
> resolved.  You also need a ChangeLog entry.

Note that sometimes it is convenient to open the doors to wider testing
with enabling something by default.  That may, in the end, result in
faster converging to an overall working system.

Richard.

> OK with those done.
>
> R.
>
>