Re: [PATCH] Allow FP to be used as a call-saved registe

["Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>]

On 15/09/16 17:36, Jeff Law wrote:
> On 09/13/2016 05:10 AM, Tamar Christina wrote:
>> Hi Jeff,
>>
>>
>> On 12/09/16 18:16, Jeff Law wrote:
>>> On 09/05/2016 08:59 AM, Tamar Christina wrote:
>>>> Hi All,
>>>>
>>>> This patch allows the FP register to be used as a call-saved
>>>> register when -fomit-frame-pointer is used.
>>>>
>>>> The change is done in such a way that the defaults do not change.
>>>> To use the FP register both -fomit-frame-pointer and
>>>> -fcall-saved-<hard_fp_reg> need to be used.
>>>>
>>>> Regression ran on aarch64-none-linux-gnu and no regressions.
>>>> Bootstrapped and ran regressions on `x86_64` and no regressions.
>>>>
>>>> A new test fp_free_1 was added to test functionality.
>>>>
>>>> Ok for trunk?
>>>>
>>>> Thanks,
>>>> Tamar
>>>>
>>>> PS. I don't have commit rights so if OK can someone apply the patch
>>>> for me.
>>>>
>>>> gcc/
>>>> 2016-09-01  Tamar Christina  <tamar.christina@arm.com>
>>>>
>>>>     * gcc/reginfo.c (fix_register): Allow FP to be set if
>>>>     -fomit-frame-pointer.
>>> I'm a little surprised you need this.  Most ports allow use of FP as a
>>> call-saved register with -fomit-frame-pointer.
>> I think this is because on most architectures the FP is not in the fixed
>> registers list. But the AArch64 ABI (I believe) currently
>> mandates that it is. With the option of:
>>
>> - It may permit the frame pointer register to be used as a
>> general-purpose callee-saved register, but provide a platform-specific
>> mechanism for external agents to reliably detect this condition
>>
>> - It may elect not to maintain a frame chain and to use the frame
>> pointer register as a general-purpose callee-saved register.
> So those don't seem to me to imply that the frame pointer needs to be a
> fixed register.   So the first thing I'd do is fix the aarch64 port to
> not do that and see what fallout there is and how to fix it.
> 
> Most ports simply don't mark the frame pointer as fixed.
> 

The AArch64 ABI specification strongly recommends that, when a frame
record is not created, the frame pointer register is left unused so that
the frame chain, while not complete, is still valid (a chain of valid
records but ending in a NULL pointer).  That strongly suggests that FP
should remain a fixed register.

I guess we could push all of this into a new back-end option to permit
the 'I really want to use FP for general purposes', but it seems to be
just duplicating the existing use of -fcall-saved; so would be yet
another flag in the compiler that needs documenting.

It seems much more sensible to me to just make a slight relaxation of
the fixed-register code and then re-use the existing options.

> I am a bit curious about how you're going to solve the "external agents
> to reliably detect this condition" :-)
> 

:-)  It's a get-out clause to pacify folk who want a completely
different ABI variant.  Reliable detection would probably mean 'a
platform convention' that all code had to conform to.

R.

>>
>>> Also note the documentation explicitly forbids using -fcall-saved for
>>> the stack or frame pointer.
>>>
>> Ah, yes, hadn't noticed that before. Isn't it a bit too strict a
>> restriction? In general if you have -fomit-frame-pointer then shouldn't
>> the it be safe for the FP to be used
>> with -fcall-saved? Since it's probably a no-op on most ports that
>> support -fomit-frame-pointer anyway?
> It might be.  In general I don't think the -fcall-whatever options are
> used that much anymore and I don't think anyone has seriously looked at
> their documentation in a long time.
> 
> Regardless, I still think the first step is to "unfix" the frame pointer
> hard register on the aarch64 port.
> 
> jeff
>