[PATCH][AArch64] LR register not used in leaf functions

Andrew Pinski pinskia@gmail.com
Sat Nov 15 15:49:00 GMT 2014


On Sat, Nov 15, 2014 at 6:08 AM, Jiong Wang
<wong.kwongyuan.tools@gmail.com> wrote:
> 2014-11-15 0:15 GMT+00:00 Andrew Pinski <pinskia@gmail.com>:
>> On Tue, Sep 30, 2014 at 8:00 AM, Jiong Wang <jiong.wang@arm.com> wrote:
>>> On 27/09/14 22:20, Kugan wrote:
>>>>
>>>>
>>>> On 23/09/14 01:58, Jiong Wang wrote:
>>
>> +      /* If we decided that we didn't need a leaf frame pointer but then used
>> + LR in the function, then we'll want a frame pointer after all, so
>> + prevent this elimination to ensure a frame pointer is used.  */
>> +      if (to == STACK_POINTER_REGNUM
>> +  && flag_omit_leaf_frame_pointer
>> +  && df_regs_ever_live_p (LR_REGNUM))
>> + return false;
>>
>> This breaks my build on aarch64-elf (with some local modifications)
>
> Hi Andrew,
>
>   then what's your local modification?
>   I think the problem is we need to figure out why there is an ICE
> after your local modification?
>   can you please send me your local modification and testcase if possible.

My local modifications can be found in the gcc git at
apinski/thunderx-cost.  Note I reverted this patch so I can continue
working.  The testcase is compiling newlib.  Let me try to get it
again.
I was configuring a combined build with:
--disable-fixed-point --without-ppl --without-python --disable-werror
--enable-plugins --enable-checking --disable-sim --with-newlib
--disable-tls --with-cpu=thunderx --with-multilib-list=lp64,ilp32
--target=aarch64-thunderx-elf --enable-languages=c,c++

Thanks,
Andrew Pinski

>
>
>> aarch64_frame_pointer_required returns true but then we use LR but now
>> aarch64_can_eliminate and aarch64_frame_pointer_required are
>> inconsitant which is not a valid thing for LRA (and reload).
>>
>> This was mentioned in https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00151.html :
>> " IRA calls hook frame_pointer_required and it returns false. After
>> that LRA calls can_eliminate hook and it returns false which means
>> that fp can not be used for allocation and we should spill all pseudos
>> assigned to it."
>>
>> Thanks,
>> Andrew Pinski



More information about the Gcc-patches mailing list