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
