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