search for: __divdi3

Are there existing "generic" implementations for these functions under the same license as LLVM? By generic I mean C or IR that doesn't use any particular HW intrinsics. I read up on divides in Knuth's Seminumerical book, but decided to use base-2 long division on the first go-around for simplicity. I know it's not very efficient and I'm looking for shortcuts to

On Oct 31, 2008, at 10:13 AM, Daniel M Gessel wrote: > Are there existing "generic" implementations for these functions under > the same license as LLVM? By generic I mean C or IR that doesn't use > any particular HW intrinsics. Hi Daniel, We're working on a complete ground-up implementation of the API vended by libgcc, including these routines, under the LLVM

...lls __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 __udivmoddi4 (254 instructions) __moddi3 (51 instructions) calls __udivmoddi4 (254 instructions) __divmoddi4 (36 instructions) calls __divdi3 (37 instructions) which calls __udivmoddi4 (254 instructions) __udivdi3 (8 instructions) calls __udivmo...

...uot;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 syntax. Again: my offer to provide these routines still stands! I have OPTIMISED __divdi3, __moddi3, __udivdi3 and __umoddi3 in Intel syntax, wrapped as inline files into an NMakefile, for use with ML.EXE. For the optimisations see the patch I sent last week. Since Howard Hinnant is NO MORE with LLVM: who is the CURRENT code owner and reviewer for the builtins library, especially for x...

...ed code; on the right the expected, properly optimised code: div: # @div push ebp | mov ebp, esp | push dword ptr [ebp + 20] | push dword ptr [ebp + 16] | push dword ptr [ebp + 12] | push dword ptr [ebp + 8] | call __divdi3 | jmp __divdi3 add esp, 16 | pop ebp | ret | long long mod(long long foo, long long bar) { return foo % bar; } mod: # @mod push ebp | mov ebp, esp |...

This fixes a long standing issue where it was not possible to do "make usr/klibc/arch/x86_64/longjmp.o" in the kernel. The principle is that all .o files to be part of klibc are listed with klib-y. For each directory a klib.list file is made that specify all .o file and the final AR then adds all .o files to create libc.a. This patch introduce the infrastructure and converts x86_64 to

> 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

The codebase sets up ogg_int32_t, etc, but then uses long directly in several structures. Unfortunately for me longs are 64 bits on my platform, not 32, and I end up getting hammered by unnecessary software math routine calls. Should I be able to just search/replace 'long' with 'ogg_int32_t' in the code or would that cause more problems than it fixes? -Dave --- >8 ---- List

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 > Info: Symbol __syslinux_adv_ptr is defined more...

...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 unsigned multiplication + * 64*64 = 64 bit signed multiplication */ .text diff -ruN klibc-0.114_orig/klibc/libgcc/__divdi3.c klibc-0.114/klibc/libgcc/__divdi3.c --- klibc-0.114_orig/klibc/libgcc/__divdi3.c 2002-08-27 22:16:15.000000000 -0700 +++ klibc-0.114/klibc/libgcc/__divdi3.c 2004-02-22 04:39:00.000000000 -0800 @@ -1,5 +1,5 @@ /* - * arch/i386/libgcc/__divdi3.c + * libgcc/__divdi3.c */ #include <stdint.h&...

Hello! We are running bitcode with JIT on visual studio project and we get strange external function call problems (jit generates jump to 00000000 address as can be seen in debugger) for libgcc functions like __fixunsdfdi, __divdi3 etc. Currently we have attached our own implementations of these functions to overcome this problem. What would be the correct way to do this on Visual Studio? Why does JIT generate such function calls at all instead of native code that executes needed operation? Thank you, Kristaps.

...System/Win32/DynamicLibrary.inc (working copy) @@ -134,6 +134,21 @@ #if defined(__MINGW32__) EXPLICIT_SYMBOL_DEF(_alloca); EXPLICIT_SYMBOL_DEF(__main); + EXPLICIT_SYMBOL_DEF(__ashldi3); + EXPLICIT_SYMBOL_DEF(__ashrdi3); + EXPLICIT_SYMBOL_DEF(__cmpdi2); + EXPLICIT_SYMBOL_DEF(__divdi3); + EXPLICIT_SYMBOL_DEF(__eprintf); + EXPLICIT_SYMBOL_DEF(__fixdfdi); + EXPLICIT_SYMBOL_DEF(__fixsfdi); + EXPLICIT_SYMBOL_DEF(__fixunsdfdi); + EXPLICIT_SYMBOL_DEF(__fixunssfdi); + EXPLICIT_SYMBOL_DEF(__floatdidf); + EXPLICIT_SYMBOL_DEF(__floatdisf); + EXPLICIT_SYMBOL_DEF(__l...

...n logic > to handle this. Maybe I'm not being very clear. I want this replacement to be done at the very last minute (before unreferenced functions are removed, of course). I only want to catch libgcc-ish functions. For example on the x86 (32) a function containing prinf() only needs __divdi3 and __moddi3. I'd like the code generator to do its magic until there is no more magic to do, and then replace any 64 bit divides with the function call, for example. Make sense? -Rich

...h,glue = CopyFromReg t6:1, Register:i64 %reg3, t6:1 t46: ch,glue = callseq_start t0, TargetConstant:i32<0> t47: ch,glue = CopyToReg t46, Register:i64 %reg0, t2 t48: ch,glue = CopyToReg t47, Register:i64 %reg1, t4, t47:1 t50: ch,glue = SHAVEISD::CALL t48, TargetExternalSymbol:i32'__divdi3', Register:i64 %reg0, Register:i64 %reg1, RegisterMask:Untyped, t48:1 t51: ch,glue = callseq_end t50, TargetConstant:i32<0>, TargetExternalSymbol:i32'__divdi3', t50:1 t52: i64,ch,glue = CopyFromReg t51, Register:i64 %reg0, t51:1 t11: ch = CopyToReg t0, Register:i64 %vr...

dahdi built fine on 5.1.20, but on 5.2.7: ............. CC [M] /home/asterisk/rpmbuild/BUILD/linux-dade6ac/drivers/dahdi/vpmadt032_loader/dahdi_vpmadt032_loader.o SHIPPED /home/asterisk/rpmbuild/BUILD/linux-dade6ac/drivers/dahdi/vpmadt032_loader/vpmadt032_x86_64.o LD [M] /home/asterisk/rpmbuild/BUILD/linux-dade6ac/drivers/dahdi/dahdi_vpmadt032_loader.o Building modules, stage 2.

Chris Lattner wrote: > On Aug 8, 2009, at 8:37 AM, Richard Pennington wrote: > >> Hi, >> >> This patch raises selected instructions to function calls. I've dome >> some preliminary testing and I works: > > Out of curiosity, why do you want this? > I do bitcode linking of a whole program, including the soft-float and other support routines that a

On Aug 8, 2009, at 11:48 AM, Richard Pennington wrote: > Chris Lattner wrote: >> On Aug 8, 2009, at 8:37 AM, Richard Pennington wrote: >> >>> Hi, >>> >>> This patch raises selected instructions to function calls. I've dome >>> some preliminary testing and I works: >> >> Out of curiosity, why do you want this? >> > > I

...before isel, still has arbitrary precision integers. The right place to do something like this is in the code generator, which is where it happens. -Chris > > I only want to catch libgcc-ish functions. > > For example on the x86 (32) a function containing prinf() only needs > __divdi3 and __moddi3. > > I'd like the code generator to do its magic until there is no more > magic > to do, and then replace any 64 bit divides with the function call, for > example. > > Make sense? > > -Rich > > _______________________________________________ >...

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

...1.6 03/12/08 10:27:49-05:00 mort@green.i.bork.org +9 -1 B hpa@zytor.com|ChangeSet|20020723064121|00000|f8a756c36aa22cad C c Add a bunch of libgcc objects. K 41984 O -rw-rw-r-- P klibc/arch/ia64/Makefile.inc ------------------------------------------------ D13 1 I13 9 arch/$(ARCH)/pipe.o \ libgcc/__divdi3.o \ libgcc/__divsi3.o \ libgcc/__udivdi3.o \ libgcc/__udivsi3.o \ libgcc/__umodsi3.o \ libgcc/__umoddi3.o \ libgcc/__udivmodsi4.o \ libgcc/__udivmoddi4.o # Patch checksum=c61569d9 -------------- next part -------------- A non-text attachment was scrubbed... Name: klibc-libgcc-fixes.diff Typ...