search for: gep

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 &A[42][0]". For the testcase, it works for instance when the struct has an...

...74598 = getelementptr [8 x <2 x float>]* %a, i32 0, i32 1, i32 1 ; <float*> [#uses=2] %tmp77 = load float* %arrayidx74598, align 4 Though we could change the algorithm to look through the vector index, it lead to an interesting question about if we should allow a getelementptr (GEP) into a vector. A vector is not like an short array of elements. It is more of an entity in itself. When dealing with vectors, it seems to me that it is cleaner to think of them as an entity and GEP to the vector and then use extract element to access the element of the vector instead o...

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

...m, etc) > > > > > > That's good. Anyway I already have a patch that is doing invariant group > > dependence across BBs, so I guess it make sense to push it upstream to > push > > the bar higher. > > But I think we are getting a little bit of topic - should gep 0 be > > canonicalized to bitcast? > > > > Are memdep/memssa the only possible passes that could benefit from > such a canonicalization or you can think of other cases when this can > be useful? > > > We already canonicalize. We canonicalize in the other direction:...

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

...default, and leave a flag to run GVN. > > - Are you doing this on the IR level, instead of in DAGCombine, because > you want the cross-block combining from GVN? Or some other reason (or both)? > Cross-block combining from GVN is one of the reasons. The second reason is we observed a GEP and its index are sometimes defined in different BBs. The third reason is we also observed a GEP and the load/store that uses it are sometimes in different BBs. Although CodeGenPrepare attempts to sink a GEP to the same BB as its load/store user, it doesn't sink GEPs with two variadic indices (...

...dep uses, > like memcpy opt, licm, etc) > > > That's good. Anyway I already have a patch that is doing invariant group > dependence across BBs, so I guess it make sense to push it upstream to push > the bar higher. > But I think we are getting a little bit of topic - should gep 0 be > canonicalized to bitcast? > Are memdep/memssa the only possible passes that could benefit from such a canonicalization or you can think of other cases when this can be useful? We already canonicalize. We canonicalize in the other direction: https://github.com/llvm-mirror/llvm/blob/...

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

...t; > >> > That's good. Anyway I already have a patch that is doing invariant group >> > dependence across BBs, so I guess it make sense to push it upstream to >> push >> > the bar higher. >> > But I think we are getting a little bit of topic - should gep 0 be >> > canonicalized to bitcast? >> > >> >> Are memdep/memssa the only possible passes that could benefit from >> such a canonicalization or you can think of other cases when this can >> be useful? >> >> >> We already canonicalize. We...

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

...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 *StrippedPtr = PtrOp->stripPointerCasts(); PointerType *StrippedPtrTy = cast<PointerType>(StrippedPtr->getType()); Namely, the stripPointerCasts function also strips address spaces. Would replacing this by stripPointerCastsSameRepresentation be...

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

...8 x <2 x float>]* %a, i32 0, > i32 1, i32 1 ; <float*> [#uses=2] > %tmp77 = load float* %arrayidx74598, align 4 > > Though we could change the algorithm to look through the vector index, > it lead to an interesting question about if we should allow a > getelementptr (GEP) into a vector. > > A vector is not like an short array of elements. It is more of an > entity in itself. When dealing with vectors, it seems to me that it > is cleaner to think of them as an entity and GEP to the vector and > then use extract element to access the element of the...

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

...ou're proposing. However, note that I can nest > arrays inside of structs and wrap structs in arrays, so I think I can > essentially almost always arrange to have arrays which I can overflow to > produce aliasing offsets. > But that doesn't matter, no? If AA is looking at two GEPs indexing into say [1 x {[0 x i32], i32}]: - we can state that gep 0, 0, 0 and gep 0, 0, 1 don't alias - even though gep 0, 0, 0, 1 and gep 0, 0, 1 can, since this is a different query. So if you have say [1 x {i32, i32}], you can safely say that gep 0, i, 0 and gep 0, j, 1 can't alias. O...

...m, etc) > > > > > > That's good. Anyway I already have a patch that is doing invariant group > > dependence across BBs, so I guess it make sense to push it upstream to > push > > the bar higher. > > But I think we are getting a little bit of topic - should gep 0 be > > canonicalized to bitcast? > > > > Are memdep/memssa the only possible passes that could benefit from > such a canonicalization or you can think of other cases when this can > be useful? > > > We already canonicalize. We canonicalize in the other direction:...

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 https://llvm.org/docs/ExtendingLLVM.html#introduction-and-warning Extending GEP would requir...

...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 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 >> &A[42][0]". For the testcase, it works for inst...

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 problems with vectors...