Review for: [ARM] Separate EABI and GNUEABI lowering

[Renato Golin via llvm-commits]

On 4 September 2015 at 05:47, Saleem Abdulrasool <compnerd at compnerd.org> wrote:
> The GNU here doesn't refer to GNU tools, but rather to the GNU *libc*, which
> does provide the function.  I think that the way you state this is a bit
> disingenuous, while a change to the invocation of clang would be sufficient
> and retain the QoI in clang.

Hi Saleem,

It's not that simple.

First of all, the fact that glibc implements the EABI wrappers is not
a guarantee that it will actually generate them, but only make them
available if the user code needs them specifically. That was done in
order to add compatibility with ARMCC code of the past, and not to
force GCC to change its behaviour when in such environment.

Second, the EABI calls are mostly wrappers to the GNU calls, since
often they have different arguments, which means they can be harder to
optimize and may incur in further penalties when used. The GNUEABI is
a *compatibility* mode, not a performing operational one.

But more importantly, this is a compiler issue, and GCC has a clear
language contract with implementations [1]:

"Most of the compiler support routines used by GCC are present in
libgcc, but there are a few exceptions. GCC requires the freestanding
environment provide memcpy, memmove, memset and memcmp."

Both kernel and Android are freestanding in that they don't use the
glibc, and because of the contract with GCC, they do implement those
library calls. The GNUEABI GCC doesn't generate "__aeabi_memcpy"
instead of "memcpy", regardless of its ABI being called ...EABI.

Furthermore, this is ISO C, and independent of the ABI being used.
Forcing such environments to implement ABI specific functions to each
platform is not technically sound.



For all the other __aeabi_* calls, it is possible that, by generating
them in Clang, we're probably making the whole code slower by actually
using the wrappers, as I said above, so for the calls which are not
offending the freestanding environments, we ought to consider not
generating the EABI counterparts as well.

The only mode where it actually makes sense is when you're using
libraries that were made for EABI, for example the ARMCC library or
other bare-metal ones. Every other library, at least on Linux, will
copy the GNU ones.

Note that none of that touches Darwin or Windows, which are already
out of the "EABI" pool anyway (see isTargetEABI). So this is a very
narrow behavioural change, one that will put Clang in sync with GCC in
its own ABI, which I believe is the correct thing to do.



My original intention was to have only EABI environments in there, but
I'm not sure why we have included the GNU in the pool. I think we need
to turn this upside down and ask the question:

* Do we have a reason to force GNUEABI to generate EABI functions?

And to treat GNUEABI as GNU, and while answering that question, make
amends for the exceptions, maybe with special flags, since it would be
a deviation of the GNU contract.

For example, the transformation for memcpy4/memcpy8 [2], is mostly
beneficial to old or embedded cores, which use "arm-none-eabi" anyway.

cheers,
--renato

[1] https://gcc.gnu.org/onlinedocs/gcc/Standards.html
[2] http://reviews.llvm.org/D8060