search for: __muldi3

I'm building tool-chain for processor without integer MUL. So, I've defined __mulsi3 for integer multiplication (int32). Now I've got a problem with int64 multiplication which is implemented in libgcc2.c. Segfualt due to infinite recursion in i64 soft multiplication (libgcc2, __muldi3). LLVM-GCC (for my target) misoptimizes code if -O2 is passed. It promotes i32 multiplication to int64 multiplication and as the result my back-end generates __muldi3 call. I would appreciate if someone can point out where this promotion happens. And how can I disable it? Thanks in advance. ......

...ol-chain for processor without integer MUL. > So, I've defined __mulsi3 for integer multiplication (int32). > > Now I've got a problem with int64 multiplication which is implemented > in libgcc2.c. > Segfualt due to infinite recursion in i64 soft multiplication > (libgcc2, __muldi3). See http://llvm.org/bugs/show_bug.cgi?id=3101 which is essentially the same issue. -Eli

> This shouldn't be necessary, IMO. If you were going to implement it, > then the correct thing to do would be to have generic selection dag > lowering of large multiplies, which renders the library mostly > useless. In fact, I would prefer to avoid custom lowering for operations on large types. i64 will be rare in my case (embedded) and their performance is not an issue. I need

On Wed, Mar 17, 2010 at 4:57 PM, Sergey Yakoushkin <sergey.yakoushkin at gmail.com> wrote: > Thanks, yes, I'm facing the same issue. > > Hm... seems there are no simple fixes. > I have to do one more i64 mul implementation to workaround aggressive > optimizations. > Is that correct? Is this the only way? This shouldn't be necessary, IMO. If you were going to

...ithout integer MUL. >> So, I've defined __mulsi3 for integer multiplication (int32). >> >> Now I've got a problem with int64 multiplication which is implemented >> in libgcc2.c. >> Segfualt due to infinite recursion in i64 soft multiplication >> (libgcc2, __muldi3). > > See http://llvm.org/bugs/show_bug.cgi?id=3101 which is essentially the > same issue. Alpha has the same problem with 128 Ints, in about the same functions.

...ill trying to track down. Still more fun to be had it seems :-) Andre -- __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools -------------- next part -------------- diff -ruN klibc-0.114_orig/klibc/arch/i386/libgcc/__muldi3.S klibc-0.114/klibc/arch/i386/libgcc/__muldi3.S --- klibc-0.114_orig/klibc/arch/i386/libgcc/__muldi3.S 2002-08-27 16:04:29.000000000 -0700 +++ klibc-0.114/klibc/arch/i386/libgcc/__muldi3.S 2004-02-22 04:39:00.000000000 -0800 @@ -1,7 +1,7 @@ /* * arch/i386/libgcc/__muldi3.S * - * 64*64 = 64 bit...

Thanks, yes, I'm facing the same issue. Hm... seems there are no simple fixes. I have to do one more i64 mul implementation to workaround aggressive optimizations. Is that correct? Is this the only way? Can I disable only one particular pass which does this promotion from i32 to i64 using some LLVM-GCC option? Are there other libgcc functions affected by this optimization? Regards, Sergey

...ch/i386/Makefile.inc | 30 +++++++ usr/klibc/arch/i386/crt0.S | 31 +++++++ usr/klibc/arch/i386/libgcc/__ashldi3.S | 29 +++++++ usr/klibc/arch/i386/libgcc/__ashrdi3.S | 29 +++++++ usr/klibc/arch/i386/libgcc/__lshrdi3.S | 29 +++++++ usr/klibc/arch/i386/libgcc/__muldi3.S | 34 ++++++++ usr/klibc/arch/i386/libgcc/__negdi2.S | 21 +++++ usr/klibc/arch/i386/open.S | 29 +++++++ usr/klibc/arch/i386/openat.S | 26 ++++++ usr/klibc/arch/i386/setjmp.S | 58 ++++++++++++++ usr/klibc/arch/i386/sigreturn.S |...

...nsl -ldl -lcrypt /opt/sparc-linux/bin/sparc-linux-ld.real: AVERTISSEMENT: ne peut trouver le symbole d'entr?e _start; utilise par d?faut 0000000000012200 readconf.o(.text+0x1014): In function `process_config_line': /usr/src/SparcV8Linux/openssh-4.6p1/readconf.c:527: undefined reference to `__muldi3' readconf.o(.text+0x1028):/usr/src/SparcV8Linux/openssh-4.6p1/readconf.c:529: undefined reference to `__divdi3' ./libssh.a(packet.o)(.text+0xab4): In function `set_newkeys': /usr/src/SparcV8Linux/openssh-4.6p1/packet.c:670: undefined reference to `__ashldi3' /opt/sparc-linux/lib/lib...

...ions) 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 instructions) __udivmodsi4 (17 instructions) calls __udivsi3 (52 instructions) __muldi3 (41 instructions) performs a "long" multiplication on 16-bit "digits" JFTR: I haven't checked whether clang actually calls these SUPERFLUOUS routines listed above. IT BETTER SHOULD NOT, NEVER! __divdi3 (37 instructions) calls __udivmo...

...ation too. > They exist for targets that don't support the operations natively. > X86 supports them natively so will never use the library functions. So they SHOULD not be built (or at least not shipped) with the builtins library for x86. > X86 has its own assembly implementation of __muldi3 that uses 32-bit > pieces. I know; that's why I placed this ABOVE my "JFTR:" > We should be using the assembly versions of the "di" division routines on > i386. Except when compiler-rt is built with MSVC because MSVC can't parse > the at&t assembly syn...

> On 06/08/2014 02:58 PM, Ady wrote: > >> > >> To be clear, I am not saying there is no bug - there might be. > >> > > > > I performed the following test with several versions of Syslinux: > > > > 1_ Execute: > > 'extlinux --once=non_default_label --install /mnt/sda1' ; > > 2_ In first reboot, the

On 06/09/2014 02:58 PM, H. Peter Anvin wrote: > > Actually, it looks more like this might be the problem: > > Info: Symbol __muldi3 is defined more than once > Info: Symbol __divdi3 is defined more than once > Info: Symbol __udivmoddi4 is defined more than once > Info: Symbol __ashrdi3 is defined more than once > Info: Symbol dev_stdcon_w is defined more than once > Info: Symbol __moddi3 is defined more than once...

...lude/arch/arm/klibc/archstat.h | 40 ++++++++++++ usr/include/arch/arm/klibc/archsys.h | 12 ++++ usr/include/arch/arm/klibc/asmmacros.h | 30 +++++++++ usr/klibc/arch/arm/MCONFIG | 36 +++++++++++ usr/klibc/arch/arm/Makefile.inc | 23 +++++++ usr/klibc/arch/arm/__muldi3.c | 15 +++++ usr/klibc/arch/arm/aeabi_nonsense.S | 9 +++ usr/klibc/arch/arm/crt0.S | 23 +++++++ usr/klibc/arch/arm/setjmp.S | 102 +++++++++++++++++++++++++++++++ usr/klibc/arch/arm/syscall.S | 61 +++++++++++++++++++ usr/klibc/arch/ar...

...ering of large MUL is supposed to work? What kind of minimalistic support should be provided by target back-end? What can be used from current LegalizeDAG? - Thanks, Sergey 2010/3/18 Sergey Yakoushkin <sergey.yakoushkin at gmail.com>: > Hi, > > LLVM mis-compiles soft int64 mul '__muldi3' (either libgcc or > compiler-rt) unless some specific efforts are taken in the back-end to > custom lower i64 operations back to i32. > > Issue appears also in CellSPU/Alpha, and there exist workarounds which > use custom lowering to vector instructions. > > My case is dif...

...m.h | 191 ++++++++++++++++++++ usr/include/arch/sparc/machine/frame.h | 146 +++++++++++++++ usr/include/arch/sparc/machine/trap.h | 140 +++++++++++++++ usr/klibc/arch/sparc/MCONFIG | 19 ++ usr/klibc/arch/sparc/Makefile.inc | 48 +++++ usr/klibc/arch/sparc/__muldi3.S | 27 +++ usr/klibc/arch/sparc/crt0.S | 2 usr/klibc/arch/sparc/crt0i.S | 100 +++++++++++ usr/klibc/arch/sparc/divrem.m4 | 276 +++++++++++++++++++++++++++++ usr/klibc/arch/sparc/pipe.S | 30 +++ usr/klibc/arch/sparc/setjmp....

> Do you have a testcase? An .ll file with no 64-bit operations, and one > optimization pass that introduces them? It's pretty common to instcombine to expand 32 bit operations to 64 bit. See, for example, recent issue with CellSPU's 32 =>64 bit muls -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello > The bitcode was generated by llvm-gcc v2.6 for Mingw32/x86, which is > available for download at the llvm site. > Please let me know, if i should tell more. Well, the answer is pretty obvious then. These calls are not generated by JIT. They are already in your bitcode - they are generated by llvm-gcc. The purpose of these calls were alreade explained by Eli. You should either

...guess this is a good starting point. Additionally, > 5.00-pre1 to 5.00-pre7 also failed, so perhaps the correction was > introduced for 5.00-pre8/9 but was not applied to the 6.xx branch on > time (nor since). > Actually, it looks more like this might be the problem: Info: Symbol __muldi3 is defined more than once Info: Symbol __divdi3 is defined more than once Info: Symbol __udivmoddi4 is defined more than once Info: Symbol __ashrdi3 is defined more than once Info: Symbol dev_stdcon_w is defined more than once Info: Symbol __moddi3 is defined more than once Info: Symbol __syslinux_...

Op 2014-06-09 om 15:41 schreef H. Peter Anvin: > On 06/09/2014 02:58 PM, H. Peter Anvin wrote: > > > > Actually, it looks more like this might be the problem: > > > > Info: Symbol __muldi3 is defined more than once > > Info: Symbol __divdi3 is defined more than once > > Info: Symbol __udivmoddi4 is defined more than once > > Info: Symbol __ashrdi3 is defined more than once > > Info: Symbol dev_stdcon_w is defined more than once > > Info: Symbol __moddi3...