[LLVMdev] GCC/LLVM frame pointer incompatibility on ARM

[Reid Kleckner]

Would they be willing to have a flag?  Would we be willing to have a flag?
 Or should we conditionalize this on OS and say, on Linux, do the gcc
thing, and on OS X, do the LLVM thing?


On Thu, Jul 17, 2014 at 6:10 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140717/04bcb0e1/attachment.html>