[LLVMdev] GCC/LLVM frame pointer incompatibility on ARM

Renato Golin renato.golin at linaro.org
Thu Jul 17 06:10:01 PDT 2014


On 17 July 2014 12:49, Yury Gribov <y.gribov at samsung.com> wrote:
> Well, their logic is that as long as FP is not part of ARM ABI they can make
> arbitrary choice even if it complicates user's life. I really hope that Renato could persuade
> people that this is worth changing.

So, this is a lot more complicated than it seems and the choice was
not arbitrary.

The old APCS required the frame pointer to be pointing to LR in the
stack, and due to the number of problems that it created [1], AAPCS
said "we're having none of it". With that in mind, the GCC engineers
didn't change the FP logic when they implemented AAPCS. The AArch64
AAPCS had a better description of what to do with the FP, and since it
was a new target, both GCC and LLVM engineers decided to do like any
other target instead.

As you may imagine, changing how the FP behaves will have an impact
not just in GCC itself, but many other tools (known and unknown) that
rely on that behaviour. So, while it's undecided and the change is
*possible*, it would need a strong argument to start that change.
Being "like the others" is not strong enough, and I agree with that.
Moreover, the AAPCS can theoretically change again, and enforce yet
another standard, where we'd have to change it all over.

For those reasons, changing ARM GCC's prologue/epilogue is probably
not happening soon.

As you probably already know, the reason why the AAPCS retreated from
controlling the FP is exactly the same as we're discussing it here.
People use it to unwind the stack. On the other hand, eliminating the
prologue when no local logic requires it is pointless and can be a big
difference in performance on devices that are already restricted by
extreme power constraints, so to produce really optimal code for ARM
you have to be able to change that.

What the AAPCS did was just to put in paper what was already true:
don't trust the prologue.

I know it's not the answer we wanted to hear, but it's a damn good
one, and one that I accept as the least costly solution. Given that
LLVM is *also* not breaking the AAPCS, I don't think it'd be a good
idea to replicate GCC's behaviour in the prologue for ARM just for the
sake of fast stack unwinding, but other people are free to disagree.

cheers,
-renato



More information about the llvm-dev mailing list