similar to: InstCombine GEP

> On Thu, Aug 10, 2017 at 12:22 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I’m not sure how transforming GEP offset to i8 type will help alias >> analysis & SROA for the mentioned test case. > > It should neither help nor hinder AA or SROA -- the two GEPs (the complex one and the simple one) are equivalent. > Since memory isn't

Hi Ashutosh, Have you been following the recent Loop Access Analysis work? LAA was split out from the Loop Vectorizer that have been performing the kind of loop versioning that you describe. The main reason was to be able to share this functionality with other passes. Loop Access Analysis is an analysis pass that computes basic memory dependence and the runtime checks. The versioning decision

I like to propose a new loop multi versioning optimization for LICM. For now I kept this for LICM only, but it can be used in multiple places. The main motivation is to allow optimizations stuck because of memory alias dependencies. Most of the time when alias analysis is unsure about memory access and it says may-alias. This un surety from alias analysis restrict some of the memory based

Hi, I have a question regarding the GEP instruction. Is it correct to consider that two GEP instructions compute the same memory address if and only if all their corresponding fields are equal? For instance, for a two-dimensional array of integers, can we have two GEP instructions that are equal?   %arrayidx = getelementptr [10 x [30 x i32]]* @main.B, i64 0, i64 0, i64 %tmp157   %tmp =

2016-12-24 9:39 GMT+01:00 Chandler Carruth <chandlerc at google.com>: > On Fri, Dec 23, 2016 at 10:17 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > > On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >

On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> >> 2016-12-23 22:17 GMT+01:00 David

On Oct 31, 2013, at 1:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Andy, et al., > > If I start with C code like this: > > void foo(long k, int * restrict a, int * restrict b, int * restrict c) { > if (k > 0) { > for (int i = 0; i < 2047; i++) { > a[i] = a[i + k] + b[i] * c[i]; > } > } > } > > Clang -O3 will produce code like

On Fri, Dec 23, 2016 at 10:17 PM Daniel Berlin <dberlin at dberlin.org> wrote: On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> wrote: On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: 2016-12-23

BTW are we planning to also remove gep 0 after we would have typeless pointers? I saw the David's presentation year ago but I am not sure if it was mentioned. If it would be removed, then does it mean that SROA would still need some new code to handle it (assuming it doesn't handle bitcasts right now) Here is the patch solving my issue https://reviews.llvm.org/D28126 2016-12-25 13:40

On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>: > > > > On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev

----- Original Message ----- > > On Oct 31, 2013, at 1:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > Andy, et al., > > > > If I start with C code like this: > > > > void foo(long k, int * restrict a, int * restrict b, int * restrict > > c) { > > if (k > 0) { > > for (int i = 0; i < 2047; i++) { > > a[i] =

Andy, et al., If I start with C code like this: void foo(long k, int * restrict a, int * restrict b, int * restrict c) { if (k > 0) { for (int i = 0; i < 2047; i++) { a[i] = a[i + k] + b[i] * c[i]; } } } Clang -O3 will produce code like this: entry: %cmp = icmp sgt i64 %k, 0 br i1 %cmp, label %for.body.preheader, label %if.end for.body.preheader: br label

On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > 2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>: > >> >> >> On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Fri, Dec 23, 2016 at 1:01 PM,

Hello I am not sure I understand the logic for merging GEPs in InstructionCombining.cpp: static bool shouldMergeGEPs(GEPOperator &GEP, GEPOperator &Src) { // If this GEP has only 0 indices, it is the same pointer as // Src. If Src is not a trivial GEP too, don't combine // the indices. if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() &&

Sorry typo in test case, Please ignore previous mail. Consider below case: for (j=1; j < itr; j++) { - - - - for (i=1; i < itr; i++) { { temp= var[i << 1]; - - - - - } } In the above example, we are unable to get "SCEVAddRecExpr" for "var[i << 1]" Its "SCEVAddRecExpr" is computable in *Outer Loop* I

Hello, could you please have a look at this code posted on godbolt.org: https://godbolt.org/z/O-O-Q7 The problem is that inside the compute function, only the first loop vectorizes while the rest copies of it don't. But if I remove any of the for loops, then the rest vectorize successfully. Could you please confirm that this is a bug, otherwise give me more insight on why the vectorization

On Mon, Feb 23, 2015 at 2:17 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Francois Pichet" <pichet2000 at gmail.com> > > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Sunday, February 22, 2015 5:34:11 PM > > Subject: [LLVMdev] Question about shouldMergeGEPs in

A GEP can represent a potentially large tree of instructions. Seems like all the sub-trees are hidden from optimization; that is, I never see licm or value numbering doing anything with them. If I rewrite the GEPs as lots of little adds and multiplies, then opt will do a better job (I speculate this happens during lowering). One of the computations that's hidden in the GEP in my example is

I suppose your view is reasonable, and perhaps common. My own "taste" has always preferred machine-independent code that is as simple as possible, so GEPs reduced to nothing more than an add, etc, i.e., quite risc-like. Then optimize it to reduce the total number of operations (as best we can), then raise the level during instruction selection, taking advantage of available instructions.

I understand that GEPs do not access memory. They do a (possibly expensive) address calculation, perhaps adding a few values to a label and leaving the result in a register. Getting a label into a register is (to me) just like loading a 64-bit integer value into a register. It can happen in many places and it can cost a few instructions and several bytes. I'd like to see such things commoned