similar to: [LLVMdev] Transforming wide integer computations back to vector computations

On Jan 2, 2012, at 10:00 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Matt, > >> 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>

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()) {

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

We use InstCombiner::ShouldChangeType() to prevent transforms to illegal integer types, but I'm not sure how that would apply to vector types. Ie, let's say v256 is a legal type in your example. DataLayout doesn't appear to specify what configurations of a 256-bit vector are legal, so I don't think we can currently use that to say v2i128 should be treated differently than v16i16.

On Thu, Jan 19, 2017 at 9:17 AM, Rackover, Zvi <zvi.rackover at intel.com> wrote: > Hi Sanjay, > > > > I agree we should also discuss **if** this canonicalization is beneficial. > > For starters, do we have a concrete case where we would benefit from > canonicalizing shuffles <-> truncates in LLVM IR? > > IMO, we should not count benefits for codegen

Hello everybody, I'm seeing LLVM (v 3.1) abort when trying to generate code that multiplies or divides 128-bit integers on x86-32. Here is a complete example 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**

Hi Jeff, > I'm seeing LLVM (v 3.1) abort when trying to generate code that > multiplies or divides 128-bit integers on x86-32. this is a known issue. The runtime library (libgcc) has routines for dividing two 64-bit integers on x86-32, but not two 128-bit integers. At least, that is how it was last time I looked. To overcome this libgcc or LLVM's compiler-rt would need to get

----- Original Message ----- > From: "deadal nix" <deadalnix at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, August 20, 2015 4:09:17 PM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan >

----- Original Message ----- > From: "deadal nix" <deadalnix at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, August 21, 2015 1:24:04 AM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan >

Hello to whom this may concern, Versioned this as I saw identical title before. I'm compiling a clang project where I'm seeing GVN mess up and replace a load with a wrong def value. I am using LLVM-3.5, but the problem has been observed upto 3.8. To illustrate the problem, define i32 @main scalar.ph: <initialize [80 x i16] %dest> ... preheader: %index=0 br test, loop1, bb2

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "deadal nix" <deadalnix at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, August 19, 2015 7:24:28 PM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan > > Hi, > > To be sure,

I'm interested in what we can do about TBAA for loads that the compiler inserts when optimizing loads into smaller loads (e.g. what SROA does). I'm gonna set the stage by using a small C snippet, because I think C has the best-understood implementation of TBAA among the folks on the list. However, I was unable to actually come up with an example where this inhibits optimizations coming

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,

Hal Finkel <hfinkel at anl.gov> wrote on 16.03.2015 17:56:20: > If you want to do it at a clang level, the right thing to do is to > fixup the ABI lowerings for pointers to keep them pointers in this case. > So this is an artifact of the way that we pass structures, and > constructing a general solution at the ABI level might be tricky. > I've cc'd Uli, who did most

Thanks for quick reply Daniel, I tried to make a simple C testcase, but could not reproduce the same condition with output from Clang. I suppose I could modify the C code to make it look similar with TBAA's; I may be able to provide this by eod. > store %ptr above the load. My mistake; I was referring to the store $lcssa in bb2. Looking at the C source code, it should definitely alias

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

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

before inlining all 20005 after inlining somewhere here changed made it NoAlias after Global Variable Optimizer 20014 20373 20255 20372 20254 before GVN 19993 20011 19991 20010 20030 It appears that TBAA metadata certainly changed after inlining and subsequent passes. I have attached the .bc file. I think I will try to dump out more TBAA metadata between passes. The method in

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

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'