Issue with frame pointer elimination

Issue with frame pointer elimination

[Henri Cloetens]

Hello,

I am working on a custom gcc.9.2.0 back end, and have an issue with 
frame pointer elimination.

- the result is OK till step '276 : ira (register allocation)
- the result is NG from step '277 onward (reload)

What it did: It used R19 for the frame pointer. This register is 
call-clobbered, but is not used for
   argument passing. Some way, it assumed to be free, but it is not.

So, the frame pointer is put in it, it is call-clobbered, and the result 
is incorrect.

If the compile flag -fomit-frame-pointer is used, the issue goes away.

Has anybody any idea where to look ?.

Best Regards,

Henri.

AW: Issue with frame pointer elimination

[Stefan Franke]

> Von: Gcc-help <gcc-help-bounces@gcc.gnu.org> Im Auftrag von Henri
> Cloetens
> Gesendet: Donnerstag, 4. Februar 2021 11:54
> An: gcc-help <gcc-help@gcc.gnu.org>
> Betreff: Issue with frame pointer elimination
> 
> Hello,
> 
> I am working on a custom gcc.9.2.0 back end, and have an issue with frame
> pointer elimination.
> 
> - the result is OK till step '276 : ira (register allocation)
> - the result is NG from step '277 onward (reload)
> 
> What it did: It used R19 for the frame pointer. This register is call-clobbered,
> but is not used for
>    argument passing. Some way, it assumed to be free, but it is not.
> 
> So, the frame pointer is put in it, it is call-clobbered, and the result is
> incorrect.
> 
> If the compile flag -fomit-frame-pointer is used, the issue goes away.
> 
> Has anybody any idea where to look ?.
> 
> Best Regards,
> 
> Henri.

Maybe R19 is used as the FRAME_POINTER? Then you can't use it for other purposes which means that no function may clobber it.

Stefan

Re: Issue with frame pointer elimination

[Segher Boessenkool]

Hi!

On Thu, Feb 04, 2021 at 11:54:09AM +0100, Henri Cloetens wrote:
> I am working on a custom gcc.9.2.0 back end, and have an issue with 
> frame pointer elimination.

It is a much better idea to use a more current GCC version, and it is
easier to upgrade now than to upgrade later.  Just a hint, do with it
what you want :-)

> - the result is OK till step '276 : ira (register allocation)
> - the result is NG from step '277 onward (reload)

Those numbers are useless to us: they depend on your configuration, and
on the exact GCC version (it often changes within one major+minor+
patchlevel as well).

The LRA pass (you do use LRA I hope?) sets up the hard frame pointer.
If you look at that dump file you can see what happened and what went
wrong (you'll probably need to look at the lra* files in the GCC source
to figure out what happened exactly, what everything means).

> What it did: It used R19 for the frame pointer. This register is 
> call-clobbered, but is not used for
>   argument passing. Some way, it assumed to be free, but it is not.

Is R19 the FRAME_POINTER_REGNUM or the HARD_FRAME_POINTER_REGNUM?  You
didn't show how you have anything of this set up, so it is hard to give
more detailed advice.

> So, the frame pointer is put in it, it is call-clobbered, and the result 
> is incorrect.
> 
> If the compile flag -fomit-frame-pointer is used, the issue goes away.
> 
> Has anybody any idea where to look ?.

You need to save the register in your prologue code if
frame_pointer_needed, etc.


Segher

Re: Issue with frame pointer elimination

[Henri Cloetens]

Hello Segher,

Ok. Then, which one would you recommend ?.

The diagnosis is indeed correct: I took the wrong one, I took R19, which 
is call clobbered.
If I take R18, the issue is solved, but it creates other problems.

Best Regards,

Henri.


On 2/5/21 12:42 AM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 04, 2021 at 11:54:09AM +0100, Henri Cloetens wrote:
>> I am working on a custom gcc.9.2.0 back end, and have an issue with
>> frame pointer elimination.
> It is a much better idea to use a more current GCC version, and it is
> easier to upgrade now than to upgrade later.  Just a hint, do with it
> what you want :-)
>
>> - the result is OK till step '276 : ira (register allocation)
>> - the result is NG from step '277 onward (reload)
> Those numbers are useless to us: they depend on your configuration, and
> on the exact GCC version (it often changes within one major+minor+
> patchlevel as well).
>
> The LRA pass (you do use LRA I hope?) sets up the hard frame pointer.
> If you look at that dump file you can see what happened and what went
> wrong (you'll probably need to look at the lra* files in the GCC source
> to figure out what happened exactly, what everything means).
>
>> What it did: It used R19 for the frame pointer. This register is
>> call-clobbered, but is not used for
>>    argument passing. Some way, it assumed to be free, but it is not.
> Is R19 the FRAME_POINTER_REGNUM or the HARD_FRAME_POINTER_REGNUM?  You
> didn't show how you have anything of this set up, so it is hard to give
> more detailed advice.
>
>> So, the frame pointer is put in it, it is call-clobbered, and the result
>> is incorrect.
>>
>> If the compile flag -fomit-frame-pointer is used, the issue goes away.
>>
>> Has anybody any idea where to look ?.
> You need to save the register in your prologue code if
> frame_pointer_needed, etc.
>
>
> Segher