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

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

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

> See ix86_return_in_memory. (In 4.3 this is renamed to > return_in_memory_32.) > i128==TImode. But TImode should be used for __m128 stuff only there, not for integers. I'm looking into gfortran now. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

> 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

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

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

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'

<moving this to llvmdev instead of commits> On Jan 22, 2008, at 11:23 PM, Duncan Sands wrote: >> Okay, well we already get many other x86-64 issues wrong already, but >> Evan is chipping away at it. How do you pass an array by value in C? >> Example please, > > I find the x86-64 ABI hard to interpret, but it seems to say that > aggregates are classified

Hi, On Monday, September 09, 2013 4:20 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: > Thanks for working on this. We usually try really hard to avoid adding new > types such as x86mmx. I don't know the memory-protection instruction set at > all but I imagine that you are not expecting other LLVM optimizations to > interact with them right ? (it looks that way from this

Hi all, I have a bunch of new registers set up in X86RegisterInfo.td, the important part being def PR128 : RegisterClass<"X86", [i128], 128, (sequence "POI%u", 0, 7)>; def VR128 : RegisterClass<"X86", [v4f32, v2f64, v16i8, v8i16, v4i32, v2i64], 128, (add PR128, FR32)>; I have an entry in

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

Hi Kevin, Can you explain what kind of abstraction/support do you plan to implement over the MP instructions ? I imagine that you plan to add a few intrinsics, right ? I imagine that you don’t need the register allocator to allocate the BND registers or anything fancy like that. In that case the registers can be an immediate in the intrinsic. Maybe you can start by presenting the kind of

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:

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:

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...

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