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

[Renato Golin]

On 22 August 2014 07:27, Saleem Abdulrasool <compnerd at compnerd.org> wrote:
> Would you happen to have a reference for the differences in the android
> case?

Unfortunately, no. I remember stepping on Android issues when
implementing EABI stuff and it being different in some aspects.

You may find clues by searching "eabi android" through the list.


> 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).

So, EABI mandates that you use EABI library calls. That's why GCC
generates them when compiling for ARM. However, GNUEABI accepts EABI
and GNUABI, so it's ok with mixing calls. I believe AndroidEABI is
closer to EABI, but different. From a GNU/EABI point of view, using
purely EABI calls would certainly work, and we could create exceptions
for Android on top of that.

But that's not the problem. The problem is to ask LLVM to generate a
call to an EABI function (say __aeabi_*divmod) just by changing the
name, but forgetting that EABI calls don't store the pointer to the
remainder in R2, but return it in either R1 or {R2, R3}. This was the
issue with the long version for divmod, and since LLVM's generic
DIVREM lowering was to assume GNU, there were two solutions:

1. To change the generic lowering to understand different calls. This
would require pseudo-ARM-specific knowledge in SelectionDAG but would
be the cleanest solution. Pseudo because we can transform ARM-talk
into return-value talk and implement other return-value types, if
needed.

2. To change the node to a fake ARM-DIVREM64 and legalize. This
legalization turned out almost impossible, and when possible
catastroficly horrible.

It may be that someone fixed that (I wasn't following recently), but
I'd expect the current tests to not change that much, especially not
by relaxing the checks that were there exactly to make sure this
complicated relationship of register return would work.


> 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.

We can't chose what to call based on performance heuristics, but on
ABI requirements. EABI mandates exclusivity, and while GNU ABI
doesn't, we should strive to.

cheers,
--renato