llvm dev - Jul 2014 - [LLVMdev] GCC/LLVM frame pointer incompatibility on ARM

On 07/16/2014 11:45 AM, Tim Northover wrote:
>>> As has been mentioned several times (*), LLVM and GCC setup frame
pointer to
>> point to different stack slots on ARM. GCC's fp points to stack
slot holding
>> lr while LLVM's fp points at the next slot.
>
> This looks flipped from my tests. Both create an { fp, lr } struct;
> GCC sets current fp to the address of lr in that struct; LLVM sets
> current fp to the address of fp in that struct.
Right, I misread the assembly :(
>> Is this incompatibility intentional/desired or we could somehow unify
GCC
>> and LLVM in this regard?
>
> What are the chances of getting GCC to change here?
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.
> It's entirely a
> bike-shedding argument, but there are a couple of reasons to prefer
> LLVM's choice. It's most consistent with what *is* required in the
> AArch64 ABI, and it means fp really points to the frame record, not
> some random point half way through it.
Yeah, I think everyone agrees on this.

-Y

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

> I know it's not the answer we wanted to hear, but it's a damn good
> one,
It's an answer. I wouldn't go any further than that myself.

Tim.

On 07/17/2014 05:10 PM, Renato Golin wrote:
> 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.
Note that these tools wouldn't work with Clang then.
And vice verse: tools that are developed in Clang (Asan) won't work with 
GCC.
> On the other hand, eliminating the
> prologue when no local logic requires it is pointless
I think you meant "keeping 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.
It's the same for x64 - if you need ability to do fast unwinding
you have to ask for it explicitly with -fno-omit-frame-pointer, 
otherwise compiler
is free to re-use rbp for general computations.

-Y

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>