similar to: [LLVMdev] Clang and i128

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:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, I'd like to ask for some advise about optimization passes. Which pass might be responsible for this LLVM IR and why? %0 = load i288* bitcast ([9 x i32]* @array to i288*), align 16 %1 = lshr i288 %0, 224 array is just a global constant array of 9 integers and the code only accesses individual elements. The LLVM version is 3.1. Thanks,

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:

Some code in GVN.cpp: static Value *CoerceAvailableValueToLoadType(Value *StoredVal, Type *LoadedTy, Instruction *InsertPt, const DataLayout &DL) { .... // Convert vectors and fp to integer, which can be manipulated. if (!StoredValTy->isIntegerTy()) {

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

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

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'

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

If you send me details about how you're building this I'll look into it. -Andy -----Original Message----- From: Mario Schwalbe [mailto:mario at se.inf.tu-dresden.de] Sent: Wednesday, May 22, 2013 2:34 AM To: Kaylor, Andrew Cc: Mario Schwalbe; LLVM Devel Subject: Re: [LLVMdev] Static linking of execution engine Hi, Am 21.05.13 21:57, schrieb Kaylor, Andrew: > Yeah, this is a problem

Hey Duncan, hey everybody else, I just stumbled upon a problem in the latest llvm-gcc trunk which is related to my previous problem with the 64bit ABI and structs: Given the following code: struct float3 { float x, y, z; }; extern "C" void __attribute__((noinline)) test(float3 a, float3* res) { res->y = a.y; } int main(void) { float3 a; float3 res; test(a,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, as the subject says, I was just wondering where the implementation of sys::fs::canonicalize() might be. The function is declared in llvm/Support/FileSystem.h, but I couldn't find its implementation within lib/Support. Consequently, any application using this function doesn't link. Am I missing something here? Regards, Mario -----BEGIN

Hi, Am 21.05.13 21:57, schrieb Kaylor, Andrew: > Yeah, this is a problem with the static constructor getting optimized out. Including "JIT.h" is supposed to fix that. > Is it possible that the file where you are including "JIT.h" doesn't have any required code in it? I'm including "JIT.h" directly in the main module, which also uses the engine. See

[+Arnold] > On Jun 10, 2015, at 1:29 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > [+CC Andy] > >> Can anyone familiar with ScalarRevolution tell me whether this is an >> expected behavior or a bug? > > Assuming you're talking about 2*k, this is a bug. ScalarEvolution > should be able to prove that {0,+,4} is <nsw> and

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

It seems that one of the optimization passes (it seems to be SROA) sometimes transforms computations on vectors of ints to computations on wide integer types; for example, I'm seeing code like the following after optimizations(*): %0 = bitcast <16 x i8> %float2uint to i128 %1 = shl i128 %0, 8 %ins = or i128 %1, 255 %2 = bitcast i128 %ins to <16 x i8> The back end I'm