llvm dev - Dec 2013 - [LLVMdev] ARM EABI and modulo

Hi all,
one issue found during the NetBSD/ARM tests is the following.
Consider this input for EARM:

    int f(int a, int b) { return a % b; }
    unsigned int g(unsigned int a, unsigned int b) { return a % b; }

At the moment, this will call __modsi3 and __umodsi3, even though those
functions are not part of AAPCS. Should this be considered a lowering
bug in the ARM target?

Joerg

Hi Joerg,
> At the moment, this will call __modsi3 and __umodsi3, even though those
> functions are not part of AAPCS. Should this be considered a lowering
> bug in the ARM target?
LLVM actually supports both variants, depending on the target. The
__aeabi_* functions are part of the ARM "runtime ABI" and largely
independent of AAPCS. For whatever reason, Linux (& Darwin) ended up
not adopting it and using those GNU functions instead.

If NetBSD uses the aeabi ones instead, it probably needs some extra
checks added to the code. I believe ELF targets currently decide based
on whether the final part of the triple is "-eabi" or not (as opposed
to "-gnueabi", ...), though I haven't looked at the code recently.

Cheers.

Tim.

On 9 December 2013 07:56, Tim Northover <t.p.northover at gmail.com>
wrote:
> If NetBSD uses the aeabi ones instead, it probably needs some extra
> checks added to the code. I believe ELF targets currently decide based
> on whether the final part of the triple is "-eabi" or not (as
opposed
> to "-gnueabi", ...), though I haven't looked at the code
recently.
Hi Tim,

You are correct, the target triple must contain "eabi", not
"gnueabi".
If you are using this on your target triple, than it's a front-end
bug, not a lowering one.

Also, note that GNU tools support the whole AEABI, so not using
gnueabi doesn't mean that it'll be incompatible with GNU tools, just
that the ARM EABI will be used instead of the GNU one.

Also note that, for 64-bit types, we still have a lowering bug where
the GNU variant is used for modulo.

This is open here:

http://llvm.org/bugs/show_bug.cgi?id=17881

and here:

http://llvm.org/bugs/show_bug.cgi?id=17193

Weiming is working on it, if this is important for you, please add
yourself to the bugs and let us know your concerns.

cheers,
--renato

On Mon, Dec 09, 2013 at 07:56:26AM +0000, Tim Northover
wrote:
> Hi Joerg,
> 
> > At the moment, this will call __modsi3 and __umodsi3, even though
those
> > functions are not part of AAPCS. Should this be considered a lowering
> > bug in the ARM target?
> 
> LLVM actually supports both variants, depending on the target. The
> __aeabi_* functions are part of the ARM "runtime ABI" and largely
> independent of AAPCS. For whatever reason, Linux (& Darwin) ended up
> not adopting it and using those GNU functions instead.
> 
> If NetBSD uses the aeabi ones instead, it probably needs some extra
> checks added to the code. I believe ELF targets currently decide based
> on whether the final part of the triple is "-eabi" or not (as
opposed
> to "-gnueabi", ...), though I haven't looked at the code
recently.
Part of the concern is that the same code using / does call __aeabi_idiv
and __aeabi_uidiv.

Joerg