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

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>

On 17 July 2014 21:08, Reid Kleckner <rnk at google.com>
wrote:
> Would they be willing to have a flag?  Would we be willing to have a flag?
That's a good question. Anything we do would be easier than wait for
them to do anything, so if we decide to go with a flag, it should be
us implementing.

> Or should we conditionalize this on OS and say, on Linux, do the gcc thing,
> and on OS X, do the LLVM thing?
I think you agree with me that both solutions are ugly, but I'd rather
not make this default behaviour anywhere, so that only who needs it
(sanitizers) turns it on with a flag.

cheers,
--renato

Having a different code path for prologue just for the sanitizers sounds pretty
risky to me. That code is already strewn with conditional and modal stuff.
Adding another variable to the permutations scares me. Is there really no
alternative? Conditional code in the sanitizers that figure things out? LLDB and
GDB have a very similar sort of problem for backtraces, including when debug
info isn’t available. How do they solve it?

-Jim

> On Jul 18, 2014, at 8:01 AM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> On 17 July 2014 21:08, Reid Kleckner <rnk at google.com> wrote:
>> Would they be willing to have a flag?  Would we be willing to have a
flag?
> 
> That's a good question. Anything we do would be easier than wait for
> them to do anything, so if we decide to go with a flag, it should be
> us implementing.
> 
> 
>> Or should we conditionalize this on OS and say, on Linux, do the gcc
thing,
>> and on OS X, do the LLVM thing?
> 
> I think you agree with me that both solutions are ugly, but I'd rather
> not make this default behaviour anywhere, so that only who needs it
> (sanitizers) turns it on with a flag.
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev