<div dir="ltr">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?</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Jul 17, 2014 at 6:10 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 17 July 2014 12:49, Yury Gribov <<a href="mailto:y.gribov@samsung.com">y.gribov@samsung.com</a>> wrote:<br>
> Well, their logic is that as long as FP is not part of ARM ABI they can make<br>
> arbitrary choice even if it complicates user's life. I really hope that Renato could persuade<br>
> people that this is worth changing.<br>
<br>
</div>So, this is a lot more complicated than it seems and the choice was<br>
not arbitrary.<br>
<br>
The old APCS required the frame pointer to be pointing to LR in the<br>
stack, and due to the number of problems that it created [1], AAPCS<br>
said "we're having none of it". With that in mind, the GCC engineers<br>
didn't change the FP logic when they implemented AAPCS. The AArch64<br>
AAPCS had a better description of what to do with the FP, and since it<br>
was a new target, both GCC and LLVM engineers decided to do like any<br>
other target instead.<br>
<br>
As you may imagine, changing how the FP behaves will have an impact<br>
not just in GCC itself, but many other tools (known and unknown) that<br>
rely on that behaviour. So, while it's undecided and the change is<br>
*possible*, it would need a strong argument to start that change.<br>
Being "like the others" is not strong enough, and I agree with that.<br>
Moreover, the AAPCS can theoretically change again, and enforce yet<br>
another standard, where we'd have to change it all over.<br>
<br>
For those reasons, changing ARM GCC's prologue/epilogue is probably<br>
not happening soon.<br>
<br>
As you probably already know, the reason why the AAPCS retreated from<br>
controlling the FP is exactly the same as we're discussing it here.<br>
People use it to unwind the stack. On the other hand, eliminating the<br>
prologue when no local logic requires it is pointless and can be a big<br>
difference in performance on devices that are already restricted by<br>
extreme power constraints, so to produce really optimal code for ARM<br>
you have to be able to change that.<br>
<br>
What the AAPCS did was just to put in paper what was already true:<br>
don't trust the prologue.<br>
<br>
I know it's not the answer we wanted to hear, but it's a damn good<br>
one, and one that I accept as the least costly solution. Given that<br>
LLVM is *also* not breaking the AAPCS, I don't think it'd be a good<br>
idea to replicate GCC's behaviour in the prologue for ARM just for the<br>
sake of fast stack unwinding, but other people are free to disagree.<br>
<br>
cheers,<br>
-renato<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>