similar to: [LLVMdev] LLVM IR i128

For 64-bit X86 code we have had good success with using up-to 128-bit integers (this includes say 36-bit or even 2-bit integers). On Mon, Feb 2, 2015 at 4:03 PM, Alejandro Velasco <gollumdelperdiguero at gmail.com> wrote: > I asked a similar question last year here. Operations on types iN with no > direct translation into one assembly instruction seem to be translated into >

Hi LLVM, 1. Can mul and/or div support be added for big integer types like i256? 2. What are the limits? 3. If yes, how should it be done? I have experience only with X86 target and know that mul i128 works and div i128 is lowered to function call from compile-rt like library (what works only if you link with such library). Can that support be extended? - Paweł -------------- next part

First off, most of my information about the integer representation in LLVM is from http://llvm.org/docs/LangRef.html#t_integer and I could use some things cleared up. First, I guess that smaller integer sizes, say, i1 (boolean) are stuffed into a full word size for the cpu it is compiled on (so 8bits, or 32 bits or whatever). What if someone made an i4 and compiled it on 32/64 bit windows/nix/bsd

Hi, I am currently working on an opencl project based on LLVM, the target device is 32bit. I met a problem that some llvm passes like GVN SROA will generate some IR operating on wide integer types like i128 or i512. But the device does not support such kind of data type. Is there any idea on how to lower this kind of IR to only operate on i32 or vector of i32? Or is there any existing code handle

Hi everyone. After lurking for a while, this is my first post to the list. I am working with some graduate students on the general topic of compiler support for SIMD programming and specific projects related to LLVM and my own Parabix technology (parabix.costar.sfu.ca). Right now we have a few course projects on the go and already a question arising out of one of them (SSE2 Hoisting).

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

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

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

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

Hi, > First, I guess that smaller integer sizes, say, i1 (boolean) are > stuffed into a full word size for the cpu it is compiled on (so 8bits, > or 32 bits or whatever). on x86-32, an i1 gets placed in an 8 bit register. > What if someone made an i4 and compiled it on 32/64 bit > windows/nix/bsd on a standard x86 or x64 system, and they set the > value to 15 (the max size of

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'

I'm trying to work out LLVM code which generates something similar to the following when adding large multiword numbers stored as separate words: ADD x1 x1 ADC x2 y2 ADC x3 y3 etc, where such a three argument add like ADC on x86 (which includes a carry in the addition) is available as a machine op. The background to this is that I'm trying to implement fast multiword addition in

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

Hi, Following is excerpted from http://llvm.org/releases/3.1/docs/LangRef.html#int_ctpop. How come the return type needs to be consistent with parameter type? i64/i128 seems to be overkill, and i8, i16 are inconvenient. ----------------------------------- declare i8 @llvm.ctpop.i8(i8 <src>) declare i16 @llvm.ctpop.i16(i16 <src>) declare i32 @llvm.ctpop.i32(i32