[llvm] r215862 - ARM: improve RTABI 4.2 conformance on Linux

[Saleem Abdulrasool]

On Thu, Aug 21, 2014 at 9:42 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 21 August 2014 17:35, Saleem Abdulrasool <compnerd at compnerd.org> wrote:
> > Sorry, Im afraid I don't understand something here.  Why would we want a
> > flag for the "bare-metal" target?  I believe both environments should
> > conform to the RTABI (which defines the functions being used).  As it
> > stands, compiler-rt (correctly, AIUI) doesn't change behavior based on
> the
> > "bare-metal" vs Linux or Android.
>
> In GNUEABI mode, _modsi3 and _divsi3 are perfectly valid replacements
> for __aeabi_divmod. In pure EABI mode, they're not. Most of the time,
> they're just aliases, so that's ok, but in divmod's case, the
> remainder comes from a different place, so it does matter. So we don't
> actually need to differentiate "bare-metal" vs. "OS", but "pure EABI"
> from "relaxed EABI". AndroidEABI is yet another variation, not
> entirely compatible with either, and not just in library calls.
>

Would you happen to have a reference for the differences in the android
case?


> Compiler-RT has both standards (AFAIK) and it doesn't change anything,
> it just provides the functionality. The problem, IIUC, is not RT, but
> the back-end emitting conflicting calls and result expectation.
>

Right.  But, libgcc as well as compiler-rt already provide the needed
functions for the standard EABI, so why not use that?  It results in
simplicity in both LLVM as well as the user code (they see the same
behavior everywhere).

As to the point of having alternatives, it seems that using the RTABI
functions where there are equivalents should be better or eequivalent to
the alternative.  In the particular example, the first call already does
most of the work for the second, and you have two calls instead of one.

cheers,
> --renato
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140821/620756ff/attachment.html>