search for: __udivmodti4

Hi Team, I observer that division of __int128 bit is very heavy operation. It internally call a routine '__udivti3', which internally call ' __udivmodti4'. Due to it the overall performance is much much slower (almost 15 time slower than if I do it via a combination of 64-bit or microsoft '_udiv128'). Also what to know if I can directly call below routine directly from my code : *unsigned long long* *__udivmodti4* *(unsigned long long...

...ST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t __udivmodti4(__uint128_t dividend, __uint128_t divisor, __uint128_t *remainder) { if (remainder != 0) *remainder = divisor; return dividend; } --- EOF --- clang -c -O1 generates the following INCOMPATIBLE and WRONG code: __udivmodti4 proc public movaps xmm0, xmmword ptr [rcx]...

...hether it will be overridden by a stronger definition. To enable inlining and other optimizations, use “linkonce_odr” linkage. This makes me think that linkonce globals will not be optimized out of an .o file, but they can be deleted by the linker. Here's some IR I have: define linkonce i128 @__udivmodti4(i128, i128, i128*) local_unnamed_addr #0 !dbg !264 { .... } When I run: opt -O3 -S compiler_rt.ll It deletes the function. Is this expected behavior? Is there a linkage type that lets the linker merge functions of the same name but does not let the optimizer delete the function? (let me know i...

On Tue, Oct 24, 2017 at 9:27 PM, Vedant Kumar <vsk at apple.com> wrote: > Unreferenced linkonce globals are allowed to be discarded. > > > Is __udivmodti4 referenced? > It's referenced by a different .o file, but nothing within the module. My confusion comes from the missing direct object in the sentence. Referenced by a function local to the module? Referenced by any object in the linker job? > > vedant > > On Oct 24, 2017, a...

Here is my test case: #include <stdio.h> int main(int argc, char **argv) { tu_int a = (tu_int)0x1ec273014 << 64 | 0xff7377ffffffffffuLL; tu_int b = (tu_int)0x8ac7230489e80000uLL; tu_int r; tu_int q = __udivmodti4(a, b, &r); utwords qt; qt.all = q; utwords rt; rt.all = r; fprintf(stderr, "q=0x%.16llX%.16llX\nr=0x%.16llX%.16llX\n", qt.s.high, qt.s.low, rt.s.high, rt.s.low); return 0; } This corresponds to the inputs a=152313999999999991610955792383 b=100000...

...lvm.org> wrote: > > Here is my test case: > > #include <stdio.h> > > int main(int argc, char **argv) { > tu_int a = (tu_int)0x1ec273014 << 64 | 0xff7377ffffffffffuLL; > tu_int b = (tu_int)0x8ac7230489e80000uLL; > tu_int r; > tu_int q = __udivmodti4(a, b, &r); > > utwords qt; > qt.all = q; > utwords rt; > rt.all = r; > fprintf(stderr, "q=0x%.16llX%.16llX\nr=0x%.16llX%.16llX\n", > qt.s.high, qt.s.low, rt.s.high, rt.s.low); > > return 0; > } > > This corresp...

...he missing clang-rt.*-i386.lib He was DEFINITELY not amused, and called the $*%@ who built this crap names. I but dared to copy clang-rt.builtins-{i386,x86-64}.lib and verified the still POOR performance, especially for 64-bit division on i386 and 128-bit division on AMD64. JFTR: __udivmoddi4 and __udivmodti4 are even slower than in LLVM 7.0.0! [...] >>> There are multiple potential equivalents to symlinks on Windows systems, >>> the one matching UNIX systems the closest is relatively new and requires >>> either Administrator rights or developer mode turned on. >> >...

...rs: noinline nounwind optnone uwtable define i128 @__udivti3(i128, i128) #0 { %3 = alloca i128, align 16 %4 = alloca i128, align 16 store i128 %1, i128* %3, align 16 store i128 %0, i128* %4, align 16 %5 = load i128, i128* %3, align 16 %6 = load i128, i128* %4, align 16 %7 = call i128 @__udivmodti4(i128 %6, i128 %5, i128* null) ret i128 %7 } declare i128 @__udivmodti4(i128, i128, i128*) #1 attributes #0 = { noinline nounwind optnone uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"=&q...

...and called the $*%@ who built this crap >> names. >> >> I but dared to copy clang-rt.builtins-{i386,x86-64}.lib and verified the >> still POOR performance, especially for 64-bit division on i386 and 128-bit >> division on AMD64. >> >> JFTR: __udivmoddi4 and __udivmodti4 are even slower than in LLVM 7.0.0! >> >> [...] >> >>>>> There are multiple potential equivalents to symlinks on Windows systems, >>>>> the one matching UNIX systems the closest is relatively new and requires >>>>> either Administrator...

...t; define i128 @__udivti3(i128, i128) #0 { > %3 = alloca i128, align 16 > %4 = alloca i128, align 16 > store i128 %1, i128* %3, align 16 > store i128 %0, i128* %4, align 16 > %5 = load i128, i128* %3, align 16 > %6 = load i128, i128* %4, align 16 > %7 = call i128 @__udivmodti4(i128 %6, i128 %5, i128* null) > ret i128 %7 > } > > declare i128 @__udivmodti4(i128, i128, i128*) #1 > > attributes #0 = { noinline nounwind optnone uwtable > "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false"...

...8) #0 { > > %3 = alloca i128, align 16 > > %4 = alloca i128, align 16 > > store i128 %1, i128* %3, align 16 > > store i128 %0, i128* %4, align 16 > > %5 = load i128, i128* %3, align 16 > > %6 = load i128, i128* %4, align 16 > > %7 = call i128 @__udivmodti4(i128 %6, i128 %5, i128* null) > > ret i128 %7 > > } > > > > declare i128 @__udivmodti4(i128, i128, i128*) #1 > > > > attributes #0 = { noinline nounwind optnone uwtable > > "correctly-rounded-divide-sqrt-fp-math"="false" > "dis...

"Michael Kruse" <llvmdev at meinersbur.de> wrote: > I think David is not referring to the capitalization of file names, but to > "DUPLICATE", "WASTING", "NOT AMUSED", "BOGUS" etc. I EMPHASIZE in the only way possible with plain text. > It should be possible to report problems in a professional manner. It should also be possible