search for: gepping

Hi all, This is covered by (struct-path aware) TBAA, but BasicAA disagrees. See the attached testcase, where it prevents us from removing the redundant load. For arbitrary GEPs, we can't decide based on constant indices (because of e.g., &A[0][1] and &A[1][0], with *A a one-element array). BasicAA has some logic to "try to distinguish something like &A[i][1] against

Hi, I ran into a case where ScalarReplAggregates can not promote an array of vectors into registers, e..g, %a = alloca [8 x <2 x float>], align 8 %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0, i32 1, i32 0 ; <float*> [#uses=2] %tmp76 = load float* %arrayidx74597, align 8 %arrayidx74598 = getelementptr [8 x <2 x float>]* %a, i32 0,

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

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

Hi, We wrote an optimization that eliminates common sub-expressions in a group of similar GEPs for the NVPTX backend. It speeds up some of our benchmarks by up to 20%, which convinces us to try to upstream it. Here's a brief description of why we wrote this optimization, what we did, and how we did it. Loops in CUDA programs are often extensively unrolled by programmers and compilers,

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

Hi Hal, Thanks for your comments! I'm inlining my responses below. Jingyue On Sat, Apr 19, 2014 at 6:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Jingyue, > > I can't speak for the NVPTX backend, but I think this looks useful as an > (optional) target-independent pass. A few thoughts: > > - Running GVN tends to be pretty expensive; have you tried EarlyCSE

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

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

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

Hi, I've been wondering why LLVMs GEP instructions are based on types, rather than encoding the raw address calculation as a base pointer plus some scaled offsets (still in the form of a GEP, to retain provenance). The type information does not seem particularly useful (shouldn't be used as an optimization base, because struct layouts lie), but increases the non-canonical IR space (there

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value

Hi, I have a doubt with GEP transformation in the instruction-combiner. Consider below test-case: struct ABC { int A; int B[100]; struct XYZ { int X; int Y[100]; } OBJ; }; void Setup(struct ABC *); int foo(int offset) { struct ABC *Ptr = malloc(sizeof(struct ABC)); Setup(Ptr); return Ptr->OBJ.X + Ptr->OBJ.Y[33]; } Generated IR for the test-case: define i32 @foo(i32

On Oct 14, 2008, at 9:50 AM, Mon Ping Wang wrote: > Hi, > > I ran into a case where ScalarReplAggregates can not promote an array > of vectors into registers, e..g, > %a = alloca [8 x <2 x float>], align 8 > %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0, > i32 1, i32 0 ; <float*> [#uses=2] > %tmp76 = load float* %arrayidx74597,

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 =

On Mon, Feb 2, 2015 at 10:59 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Feb 2, 2015 at 10:55 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: > >> Ah yes, the structs are what make it messy. >> >> How about the more useful constraint: >> - the (identical) base must point to a (possibly multidimensional) array >>

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

Am Mo., 22. Juli 2019 um 10:50 Uhr schrieb Doerfert, Johannes <jdoerfert at anl.gov>: > Why introduce a new intrinsic (family)? It seems that would require us > to support GEPs and GEP + "multi-dim" semantics in various places. What is > the benefit over a GEP extension? Adding an intrinsic is easier than adding or extending an existing instruction, as suggested by

On Sat, Jan 24, 2015 at 5:44 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Tue, Jan 20, 2015 at 12:27 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com > > wrote: > >> Hi all, >> >> This is covered by (struct-path aware) TBAA, but BasicAA disagrees. >> See the attached testcase, where it prevents us from removing the >> redundant

On Oct 14, 2008, at 11:02 AM, Duncan Sands wrote: > Hi Mon Ping, > >> I would like to make it illegal to GEP into a vector as I think it is >> cleaner and more consistent. Opinions? Comments? > > now that arrays are first class types, I think vectors should become > a subclass of ArrayType. This would get rid of a lot of duplicated > code, and also fix a bunch of