This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Aarch64] LRA
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Evandro Menezes <e dot menezes at samsung dot com>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 6 Nov 2014 15:11:27 -0800
- Subject: Re: [Aarch64] LRA
- Authentication-results: sourceware.org; auth=none
- References: <076b01cff91b$fe258a20$fa709e60$ at samsung dot com> <545A62FF dot 3080404 at arm dot com> <084b01cffa15$ee8dc780$cba95680$ at samsung dot com>
On Thu, Nov 6, 2014 at 3:03 PM, Evandro Menezes <e.menezes@samsung.com> wrote:
> That's what I assumed. However, can reload spill GPRs into FPRs as LRA
> does? For even after specifying -mno-lra, I still see excessive slots in
> FPRs.
Not fully. What is happening most likely is IRA is deciding to use
some FPRs for some psedu-registers due to the costs (look at the .ira
dump) and then reloading from FPRs to GPRs.
Thanks,
Andrew
>
> Thank you,
>
> --
> Evandro Menezes Austin, TX
>
>
>> -----Original Message-----
>> From: Richard Earnshaw [mailto:rearnsha@arm.com]
>> Sent: Wednesday, November 05, 2014 11:49
>> To: Evandro Menezes; gcc@gcc.gnu.org
>> Subject: Re: [Aarch64] LRA
>>
>> On 05/11/14 17:14, Evandro Menezes wrote:
>> > It doesn't seem that the option -mno-lra does what it implies. If so,
>> > what does it do, for the it does result in differences.
>>
>> It causes the compiler to use 'reload' rather than LRA for handling part
> of
>> the register allocation process.
>>
>> R.
>
>