similar to: [LLVMdev] ABI for i128 on x86-32?

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

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

Most probably you need to properly specify the calling convention the backend is using for calling the runtime functions. Or implement the stub for udivti3 that performs the necessary argument lifting. I guess there is no standard ABI document describing the intended calling convention here, so I'd just do what mingw64 does here and make everything here compatible. On Thu, Apr 26, 2018 at

On Thu, Apr 26, 2018 at 3:44 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Most probably you need to properly specify the calling convention the > backend is using for calling the runtime functions. Thanks for the tip. Can you be more specific? Are you suggesting there is some config parameter I can set before running TargetMachineEmitToFile? Do you know what

I'm trying to use LLVM to create compiler-rt.o on Windows. I use this command from the compiler-rt project: [nix-shell:~/downloads/llvm-project/compiler-rt]$ clang -nostdlib -S -emit-llvm lib/builtins/udivti3.c -g -target x86_64-windows -DCRT_HAS_128BIT The resulting LLVM IR is: ================================================================= ; ModuleID = 'lib/builtins/udivti3.c'

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:

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 automatically splitting an argument into multiple registers. Is the backend the best

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 HTML attachment was scrubbed...

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

On Fri, Aug 19, 2011 at 1:59 PM, Craig Smith <craig at ni.com> wrote: > 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:

Hi, I have a set of new registers for x86 which I defined in X86RegisterInfo.td to be: def POI0: X86Reg<"poi0", 0>; def POI1: X86Reg<"poi1", 1>; def POI2: X86Reg<"poi2", 2>; def POI3: X86Reg<"poi3", 3>; def POI4: X86Reg<"poi4", 4>; def POI5: X86Reg<"poi5", 5>; def POI6: X86Reg<"poi6",

Hi all, I currently use LLVM 3.0 clang to compile my source code to bitcode (on a X86-64 machine) before it is later processed by a pass, like this: $ clang -m32 -O3 -S foo.c -emit-llvm -o foo.ll However, for some reason the the resulting module contains 128-bit instructions, e.g.: %6 = load i8* %arrayidx.1.i, align 1, !tbaa !0 %7 = zext i8 %6 to i128 %8 = shl nuw nsw i128 %7, 8 which the

Hello, Dan > Does anyone know of any precedent for handling i128 in the > calling convention on x86-32? Never seen this 'in wild' (pure integer case). > 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. Can XMM registers be used for such things? -- With best

> Anton mentioned that Fortran uses i128 on 32-bit systems, Anton do you > know if they can be returned, and if so what ABI they use? Looks like, that warning is generated during emission of decl of __sync_fetch_and_add_16. I don't have any gcc 4.2.x+ here, so if somebody have it available on 32-bit machine - please check the stuff. -- With best regards, Anton Korobeynikov. Faculty

Anyone run across __fixunsdfti relocation problems while building the llvm gcc frontend on an AMD-64 box under linux? For some reason, TImode is turned on but the bootstrap xgcc compiler complains that 128-bit integers are not supported. Any clues on a workaround?

This is not yet supported by the llvm x86 backend. Perhaps there is a configuration option (or you may have to hack up some files in config/ i386) to disable gcc long double support? Evan On Oct 9, 2006, at 11:50 AM, Scott Michel wrote: > Anyone run across __fixunsdfti relocation problems while building the > llvm gcc frontend on an AMD-64 box under linux? For some reason, > TImode

This is a maintenance release of Number Nine Imagine 128 DDX. There was one patch that has been languishing over at Patchwork X.org website (https://patchwork.freedesktop.org/patch/122831/) for more than 2 years, so I decided to apply it, and release a new version. With that patch applied and one more small patch I authored, the DDX compiles cleanly without compilation warnings. Kevin Brace

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: fixup typo Matthieu Herrb

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 -Wunused-const-variable warnings

Last-minute fix for 7.4. Adam Jackson (1): Don't store pScrn->monitor->DDC manually, let xf86SetDDCproperties do it. Julien Cristau (1): Bump to 1.3.1 Paulo Cesar Pereira de Andrade (2): Compile warning fixes. Replace calls to xf86usleep with calls to usleep and include unistd.h. git tag: xf86-video-i128-1.3.1