similar to: [LLVMdev] LiveIntervals analysis problem

On Thu, Jan 26, 2012 at 3:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Thu, 2012-01-26 at 15:12 -0600, Sebastian Pop wrote: >> On Thu, Jan 26, 2012 at 2:49 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> > Thanks! Did you compile with any non-default flags other than -mllvm >> > -vectorize? >> >> I used -O3 and -vectorize, no other non-default

Hi all, I am working on an llvm backend for a processor with a relative simple instruction set. For small loops, the code that is produced depends heavily on how the loop is specified: The less information we provide to clang, the better the loop code becomes... Any idea how I can learn llvm that we don't have load/store instructions with register index, so that it is more efficient to

> Fixing that still gives a wrong result, i haven't started to track down what *else* is going on here. Running with the attached diff + a modified buildGraphFrom to handle the constexpr GEPs, we seem to flag everything in test2.ll (conservatively) correctly. Is `store` the only place we can expect to see these constexpr analogs, or is just about anywhere fair game? George On Fri, Jan

Without the patch is also returns the wrong answer for all of these, it just doesn't cause LICM to promote because it returns PartialAlias (which is still wrong). We return may-alias instead, and now suddenly it's happy to promote them. The broken noalias results exist both before and after my patch: ===== Alias Analysis Evaluator Report ===== 521 Total Alias Queries Performed

No, i mean the actual store instruction looks like "store i16 %conv22, i16* getelementptr inbounds ([16 x i16]* @pA, i64 0, i64 12), align 2, !tbaa !1" Not that the pointer operand comes from a GEP, but it is a constantexpr, whose opcode is GEP. It sucks that there is such a complex thing to be handled as a store operand directly , but such is life ... CFL-AA *should* treat this

Hello all, My app is using LLVM JIT as a runtime engine for image analysis (similar to opencl). I'm placing values into a struct to pass byref to a series of functions. After running the createStandardModulePasses(...) set of optimizations, the function calls are all inlined but the struct store/load pairs haven't been optimized away. I've attached the code below. What I'd like to

Hello all, My app is using LLVM JIT as a runtime engine for image analysis (similar to opencl). I'm placing values into a struct to pass byref to a series of functions. After running the createStandardModulePasses(...) set of optimizations, the function calls are all inlined but the struct store/load pairs haven't been optimized away. I've attached the code below. What I'd like to

Hi, I'm trying to get the following loop to vectorize (simple reduction): unsigned int sum2(unsigned int *a, int len){ unsigned int s = 0; for (int i = 0; i < len; i += 4) s += *a++; return s; } The loop fails to vectorize because SCEV could not compute the loop exit count. It appears SCEV cannot handle the non-unit increment of the loop counter. Is this a known limitation of

It works, thank you, Andy. On Thu, Jun 20, 2013 at 12:45 AM, Andrew Trick <atrick at apple.com> wrote: > > On Jun 19, 2013, at 1:04 AM, Eric Lu <eirc.lew at gmail.com> wrote: > > It seems the options still does not work, or I have misunderstood what you > said. > > The command: > clang -g -I/home/lxj/software/llvmsvn/include -emit-llvm $1.c -c -o > $1.bc

On 22 August 2013 13:24, Redmond, Paul <paul.redmond at intel.com> wrote: > Hi, > > I'm trying to get the following loop to vectorize (simple reduction): > > unsigned int sum2(unsigned int *a, int len){ > unsigned int s = 0; > for (int i = 0; i < len; i += 4) > s += *a++; > return s; > } > > > The loop fails to vectorize because SCEV

The scoreboard hazard detector that I've added for the PPC 440 is not detecting hazards as it should (which certainly could be my fault somehow, but...). For example, it will produce a schedule that looks like... SU(28): 0x127969b0: f64,ch = LFD 0x12793aa0, 0x1277b4f0, 0x127965b0<Mem:LD8[%scevgep100](tbaa=!"double")> [ORD=41] [ID=28] SU(46): 0x12796ab0: f64 = FADD 0x127969b0,

Hi, I have experimented with enabling the LoopVectorizer for SystemZ. I have come across a loop which, when vectorized, seems to have been poorly generated. In short, there seems to be a completely unnecessary sequence of shufflevector instructions, that doesn't get optimized away anywhere. In other words, there is a shuffling so that leads back to the original vector: [0 1 2 3

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

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

Hi, Found CloneBasicBlock utility only does the cloning without any remapping. Consider below example: Input block: sw.epilog: ; preds = %sw.bb20, %sw.bb15, %sw.bb10, %sw.bb6, %sw.bb2, %sw.bb, %while.body, %if.end29 %no_final.1 = phi i32 [ %no_final.055, %while.body ], [ 1, %if.end29 ], [ %no_final.055, %sw.bb20 ], [ %no_final.055, %sw.bb15 ], [

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

On some targets with limited addressing modes, getting that 64-bit relocatable but loop-invariant value into a register requires several instructions. I'd like those several instruction outside the loop, where they belong. Yes, my experience is that something (I assume instcombine) recanonicalizes. Thanks, Preston On Tue, Dec 8, 2015 at 11:21 PM, Mehdi Amini <mehdi.amini at

Renato, can you post a hand-created vectorized IR of how a reduction would work on your example? I don’t think that recognizing this as a reduction is going to get you far. A reduction is beneficial if the value reduced is only truly needed outside of a loop. This is not the case here (we are storing/loading from the pointer). Your example is something like WRITEPTR = phi i8* [ outsideval,

Renato, This looks like the right direction. Did you run it on the LLVM test suite to check if it finds new loops to vectorize ? Thanks, Nadav On Oct 21, 2013, at 8:23 AM, Renato Golin <renato.golin at linaro.org> wrote: > Hi Nadav, Arnold, > > I managed to find some time to work on the pointer reduction, and I got a patch that can make "canVectorize()" pass. >

I come across a situation that I am having a hard time to understand. When I compile the following code : char *tst( char *dest, const char *src, unsigned int len ) { for (int i=0 ; i<len ; i++) { dest[i] = src[i]; } return dest; } Clang generates this for the ‘for’ body: for.body: ; preds = %for.cond %arrayidx = getelementptr inbounds i8,