On Mon, Dec 09, 2013 at 01: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 __umodsi3I 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
On Mon, Dec 09, 2013 at 03:11:45PM +0100, Joerg Sonnenberger wrote:> On Mon, Dec 09, 2013 at 01: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....but it should be using __aeabi_*mod in that case. Joerg
On 9 December 2013 14:11, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> 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.This is not just about being faster, but also compliant. If you have to follow the EABI, then you cannot guarantee that you'll have the __umodsi3 anywhere in any library. If you follow the GNU EABI, than you have no guarantee that __aeabi_uidivmod will. Regardless of the performance discussion, I opened this bug: http://llvm.org/bugs/show_bug.cgi?id=18187 because of its inconsistency. If you want to call __umodsi3 instead of __uidivmod, than you should use GNUEABI. When you need both, calling the EABI variant is faster (only one function call), but I don't think we should mix the two variants in EABI mode. If the GNUEABI wants to do that, I don't think it's wrong, but lets not do this on EABI mode. cheers, --renato
On 9 December 2013 14:17, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> ...but it should be using __aeabi_*mod in that case.There are no __aeabi_*mod variants. EABI 4.3.1: Aside: Separate modulo functions would have little value because modulo on its own is rare. Division by a constant and constant modulo can be inlined efficiently using (64-bit) multiplication. For implementations in C, __value_in_regs can be emulated by tail-calling an assembler function that receives the values to be returned as arguments and, itself, returns immediately. cheers, --renato