search for: i128

...============= ; ModuleID = 'lib/builtins/udivti3.c' source_filename = "lib/builtins/udivti3.c" target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64--windows-msvc19.11.0" ; Function Attrs: 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...

...#39;lib/builtins/udivti3.c' > source_filename = "lib/builtins/udivti3.c" > target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128" > target triple = "x86_64--windows-msvc19.11.0" > > ; Function Attrs: 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(i...

...; > > source_filename = "lib/builtins/udivti3.c" > > target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128" > > target triple = "x86_64--windows-msvc19.11.0" > > > > ; Function Attrs: 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 > &g...

I think from the C compiler's point of view, it is going to want it to work for any size above an i64, i.e. all the way up to an i128 so that if the user of the C compiler does this computation with __uint128_t's then it will Do The Right Thing TM. Basically, you want unsigned long a, b, c, d; .... const __uint128_t u = (__uint128_t) a + b; const unsigned long v = u >> 64; const __uint128_t w = (__uint128_t) c + d +...

...1.6 cycles. >>> >>> The part of the loop in question becomes: >>> >>> %tmp.i = add i64 %indvar.i, 1                   ; <i64> [#uses=2] >>>  %22 = load i64* %scevgep.i, align 8             ; <i64> [#uses=1] >>>  %23 = zext i64 %22 to i128                      ; <i128> [#uses=1] >>>  %24 = load i64* %scevgep3.i, align 8            ; <i64> [#uses=1] >>>  %25 = zext i64 %24 to i128                      ; <i128> [#uses=1] >>>  %26 = zext i64 %cy.02.i to i128                 ; <i128> [#u...

> Yeah I had a think about it, and I think intrinsics are the wrong way > to do it. So I'd say you are likely right. For this to work well, the way the code generators handle flags will need to be improved: currently it is suboptimal, in fact kind of a hack. Ciao, Duncan.

I am seeing i128 from llvm-gcc on Alpha.  I know the calling convention for them, they are split into two registers, but I don't know if that should be handled in the frontend or the backend.  I would just as soon do it in the backend, but I didn't see any support in the new calling convention work for auto...

Hello, Does anyone know of any precedent for handling i128 in the calling convention on x86-32? I'm trying to write a testcase that returns an i128 value, and LLVM currently has only two 32-bit GPRs designated for returning integer values on x86-32. Dan

...configure.ac bug URL for gitlab migration Kevin Brace (2): Use const char for xf86GetOptValString return type Version bumped to Version 1.4.0 Laurent Carlier (1): Stop using deprecated xf86PciInfo.h Mihail Konev (1): autogen: add default patch prefix git tag: xf86-video-i128-1.4.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-i128-1.4.0.tar.bz2 MD5: a980f1b8532ccfe81932580bc4e0f2a0 xf86-video-i128-1.4.0.tar.bz2 SHA1: 56d5b897b2695222c13e59d2ade74620a99e1011 xf86-video-i128-1.4.0.tar.bz2 SHA256: 8f2c0a6bf5a169dad3fc07c6dd4537b492d0e44489e4a129731...

...roll, I get 2.5 cycles. But optimal is actually 1.6 cycles. > > The part of the loop in question becomes: > > %tmp.i = add i64 %indvar.i, 1                   ; <i64> [#uses=2] >  %22 = load i64* %scevgep.i, align 8             ; <i64> [#uses=1] >  %23 = zext i64 %22 to i128                      ; <i128> [#uses=1] >  %24 = load i64* %scevgep3.i, align 8            ; <i64> [#uses=1] >  %25 = zext i64 %24 to i128                      ; <i128> [#uses=1] >  %26 = zext i64 %cy.02.i to i128                 ; <i128> [#uses=1] >  %27 = add i...

This is the Xorg driver for Number Nine Imagine 128 (I128) video cards, which were sold in the mid-to-late 1990's for PCI & AGP bus systems. Alan Coopersmith (8): Build xz tarballs instead of bzip2 Fix spelling/wording issues gitlab CI: add a basic build test gitlab CI: stop requiring Signed-off-by in commits Handle...

Adam Jackson (3): Death to RCS tags. Fix distcheck i128 1.3.0 Alan Coopersmith (2): Replace references to XFree86/XF86Config in man page renamed: .cvsignore -> .gitignore Brice Goglin (1): Define I128_*_VERSION* using PACKAGE_VERSION_* Dave Airlie (3): i128: pciaccess conversion i128: drop ansi C wrapper i128: f...

...I fiddle a bit and loop unroll, I get 2.5 cycles. But optimal is actually 1.6 cycles. The part of the loop in question becomes: %tmp.i = add i64 %indvar.i, 1 ; <i64> [#uses=2] %22 = load i64* %scevgep.i, align 8 ; <i64> [#uses=1] %23 = zext i64 %22 to i128 ; <i128> [#uses=1] %24 = load i64* %scevgep3.i, align 8 ; <i64> [#uses=1] %25 = zext i64 %24 to i128 ; <i128> [#uses=1] %26 = zext i64 %cy.02.i to i128 ; <i128> [#uses=1] %27 = add i128 %23, %26...

In both LLVM 2.9 and the current svn head, I get the following error when running llc % llc < fxp2.ll LLVM ERROR: Cannot select: 0xa5302b0: glue = carry_false [ID=7] on this code: target triple = "i386-pc-linux-gnu" define i32 @fxpadd(i32 %cl) { entry: %0 = zext i32 %cl to i128 %1 = zext i32 %cl to i128 %2 = add i128 %1, %0 br label %L1001510 L1001510: ; preds = %L13400 %vr1484.5 = trunc i128 %2 to i32 ret i32 %vr1484.5 } This code was whittled down from a fixed point math test by bugpoint, and further simplified by han...

Hi everyone! Here, I have a question and am curious about i128. I want to know how the LLVM handle i128, because many compiler backend doesn't support i128 directly. So I am very curious and want to how the llvm handle this situation? Besides i128, such as i256, i512, even i24? Thanks. Best Regards Wu Zhao -------------- next part -------------- An H...

...t optimal is actually 1.6 cycles. >> >> The part of the loop in question becomes: >> >> %tmp.i = add i64 %indvar.i, 1 ; <i64> [#uses=2] >> %22 = load i64* %scevgep.i, align 8 ; <i64> [#uses=1] >> %23 = zext i64 %22 to i128 ; <i128> [#uses=1] >> %24 = load i64* %scevgep3.i, align 8 ; <i64> [#uses=1] >> %25 = zext i64 %24 to i128 ; <i128> [#uses=1] >> %26 = zext i64 %cy.02.i to i128 ; <i128> [#uses=1] >&...

Hello, Andrew > Is the backend the best place to do this or should I attempt to make > llvm-gcc not generate i128 in the first place? It depends whether i128 is a native type for alpha, or not. If it's not - frontend should not generate it. If it's native type then it might be useful just to declare new regclass with virtual 'wide' registers consist of register pairs and then just handle i128 a...

...ample function: define %jl_value_t* @foo564(%jl_value_t*, %jl_value_t**, i32) { top: %3 = load %jl_value_t** %1, align 4, !dbg !5139 %4 = getelementptr inbounds %jl_value_t* %3, i32 0, i32 0, !dbg !5139 %5 = getelementptr %jl_value_t** %4, i32 1, !dbg !5139 %6 = bitcast %jl_value_t** %5 to i128*, !dbg !5139 %7 = load i128* %6, align 4, !dbg !5139 %8 = mul i128 %7, 137, !dbg !5146, !julia_type !5147 %9 = call %jl_value_t* @allocobj(i32 20), !dbg !5146 %10 = getelementptr inbounds %jl_value_t* %9, i32 0, i32 0, !dbg !5146 store %jl_value_t* inttoptr (i32 159792480 to %jl_value_t*)...

I think it's returned in 4 registers: eax, edx, esi, edi. Can someone confirm? Evan On Feb 27, 2008, at 8:33 AM, gohman at apple.com wrote: > Hello, > > Does anyone know of any precedent for handling i128 in the > calling convention on x86-32? I'm trying to write a testcase > that returns an i128 value, and LLVM currently has only two > 32-bit GPRs designated for returning integer values on x86-32. > > Dan > > > _______________________________________________ > LLVM De...

...I get the following error when running llc > > % llc < fxp2.ll > LLVM ERROR: Cannot select: 0xa5302b0: glue = carry_false [ID=7] > > on this code: > > target triple = "i386-pc-linux-gnu" > > define i32 @fxpadd(i32 %cl) { > entry: >  %0 = zext i32 %cl to i128 >  %1 = zext i32 %cl to i128 >  %2 = add i128 %1, %0 >  br label %L1001510 > > L1001510:                                         ; preds = %L13400 >  %vr1484.5 = trunc i128 %2 to i32 >  ret i32 %vr1484.5 > > } > > This code was whittled down from a fixed point math...