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

Saleem Abdulrasool compnerd at compnerd.org
Thu Aug 21 09:35:40 PDT 2014


On Thu, Aug 21, 2014 at 5:19 AM, Moritz Roth <moritz.roth at arm.com> wrote:

> Hi Saleem,
>
> >Hmm, somehow I missed that when I glanced at the asm output you sent out
> >earlier.  That area does look incorrect.  You said that this same code
> >works for -eabi targets?
>
> Yes, and I think I've found out why now - we have custom lowering for
> SDIVREM/UDIVREM in ARMISelLowering.cpp, but on non-EABI targets that's
> not used / overwritten (see ARMISelLowering.cpp:395 and :718).
>
> If I change the check on line 718 to something like
>         if (!isTargetAEABI() && !isTargetGNUEABI()) {
> and define isTargetGNUEABI in the obvious way in ARMSubtarget.h,
> the custom lowering is used for GNUEABI as well and the failures seem
> to go away.
>
> This is sort of a wild guess, but I think the proper way to fix this is
> described in ARMSubtarget.h, where isTargetAEABI is defined:
>
>   // ARM EABI is the bare-metal EABI described in ARM ABI documents and
>   // can be accessed via -target arm-none-eabi. This is NOT GNUEABI.
>   // FIXME: Add a flag for bare-metal for that target and set Triple::EABI
>   // even for GNUEABI, so we can make a distinction here and still conform
> to
>   // the EABI on GNU (and Android) mode. This requires change in Clang,
> too.
>

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.


> Joey actually pointed me at LowerDivRem from the beginning, but somehow
> I didn't figure this out the first few times around...
>
> Cheers
> Moritz
>
>
>
>


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


More information about the llvm-commits mailing list