search for: __modsi3

Hi, I see there is an inconsistency in LLVM libc calls. For a modulo (reminder) operation, clang -target arm-none-linux-gnueabi generates "__modsi3". clang -target arm-none-eabi generates "__aeabi_idivmod" clang -target arm-linux-androideabi generates "__modsi3" Android bionic libc doesn't provide a __modsi3, instead it provides "__aeabi_idivmod". I wonder why no one has seen this issue so far. Is...

Hi All, The default implementation of __modsi3() (signed integer modulus) in compiler-rt/lib/modsi3.c is defined recursively. Thankfully, LLVM is smart enough to do tail call elimination on the recursion, so I got an infinite loop rather than a stack overflow :) Here's the patch, patterned after the correct implementation in umod...

On 28 July 2015 at 17:52, Sumanth Gundapaneni <sgundapa at codeaurora.org> wrote: > Android bionic libc doesn’t provide a __modsi3, instead it provides > “__aeabi_idivmod”. Hi Sumanth, Have a look at ARMSubtarget.h, functions: bool isTargetAEABI() They control the lowering of DIV/MOD calls in ARMISelLowering.cpp. Maybe Android needs to be in? 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 la...

Hi all, Sorry for bothering those not interested. I found that ARM backend will insert a modulo function (like __modsi3) instead of the modulo instruction. I wonder how we can inline the modulo function into the program. Is there any OPTION we can use in the opt or llc? Thanks, Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachment...

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

...using / does call __aeabi_idiv > and __aeabi_uidiv. Hi Joerg, I can see the error, and it's just a bad selection of choices. I was wrong in assuming that the "eabi" at the end would always force it: $ clang -target arm-elf-eabi -S mod.c -o - | grep mod .file "mod.c" bl __modsi3 bl __umodsi3 $ clang -target arm-none-eabi -S mod.c -o - | grep mod .file "mod.c" bl __aeabi_idivmod bl __aeabi_uidivmod This is clearly a bug and should be fixed. Please file a bug in bugzilla and I'll have a look at it. cheers, --renato

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

...1:58:29PM +0000, Renato Golin wrote: > I can see the error, and it's just a bad selection of choices. I was > wrong in assuming that the "eabi" at the end would always force it: > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > .file "mod.c" > bl __modsi3 > bl __umodsi3 I was discussing this with Tim on IRC and he raised the valid question of a pure mod operation being faster when emulated as it doesn't have to keep track of the quotient. So it really boils down to whether it has a fancy enough dress to be called a feature. Joerg

...rs giving a 64-bit product! I expect that a library written 20+ years later takes advantage of these instructions! __divsi3 (18 instructions) perform a DIV after 2 calls of abs(), plus a final negation, instead of just a single IDIV __modsi3 (14 instructions) calls __divsi3 (18 instructions) __divmodsi4 (17 instructions) calls __divsi3 (18 instructions) __udivsi3 (52 instructions) does NOT use DIV, but performs BITWISE division using shifts and additions! __umodsi3 (14 instructions) calls __udivsi3 (52 inst...

...rary written 20+ years later takes >> advantage of these instructions! >> >> __divsi3 (18 instructions) perform a DIV after 2 calls of abs(), >> plus a final negation, instead of just >> a single IDIV >> __modsi3 (14 instructions) calls __divsi3 (18 instructions) >> __divmodsi4 (17 instructions) calls __divsi3 (18 instructions) >> >> __udivsi3 (52 instructions) does NOT use DIV, but performs BITWISE >> division using shifts and additions! >> __umodsi...

...wrote: > > I can see the error, and it's just a bad selection of choices. I was > > wrong in assuming that the "eabi" at the end would always force it: > > > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > > .file "mod.c" > > bl __modsi3 > > bl __umodsi3 > > I was discussing this with Tim on IRC and he raised the valid question > of a pure mod operation being faster when emulated as it doesn't have to > keep track of the quotient. So it really boils down to whether it has a > fancy enough dress to be calle...

...1:26 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Ray, > > On 10 November 2014 10:13, Alex S <alexmountain13 at gmail.com> wrote: > > Sorry for bothering those not interested. I found that ARM backend will > > insert a modulo function > > (like __modsi3) instead of the modulo instruction. I wonder how we can > > inline the modulo function > > into the program. Is there any OPTION we can use in the opt or llc? > > It depends on whether the CPU actually supports integer division. > Surprisingly modern CPUs don't (the Cortex-...

...ile.inc klibc-0.114/klibc/arch/arm/Makefile.inc --- klibc-0.114_orig/klibc/arch/arm/Makefile.inc 2002-09-16 09:47:55.000000000 -0700 +++ klibc-0.114/klibc/arch/arm/Makefile.inc 2004-02-22 06:35:37.000000000 -0800 @@ -8,6 +8,7 @@ # ARCHOBJS = \ + arch/arm/exits.o \ libgcc/__divsi3.o \ libgcc/__modsi3.o \ libgcc/__udivsi3.o \ @@ -17,10 +18,28 @@ libgcc/__moddi3.o \ libgcc/__udivdi3.o \ libgcc/__umoddi3.o \ - libgcc/__udivmoddi4.o + libgcc/__udivmoddi4.o \ + arch/arm/libgcc/__muldi3.o + +THUMBOBJS = \ + arch/arm/libgcc/_call_via_r0.o \ + arch/arm/libgcc/_call_via_r1.o \ + arch/arm/libgcc/...

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at: