search for: geps

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

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

...; and always canonicalize gep 0 to bitcast. > > > +1 > > This canonicalization seems like it's unlikely to help other passes, and > definitely makes handling more complicated elsewhere. > > > -1 > ;] > > I think it is very useful to be able to canonicalize on GEPs rather than > bitcasts. > > > Based on what? > > > TBH, no hard data at all. Just my experience poking at passes that cared > about this and the advice I received from others when hacking on them. > Sorry if anything I wrote came off as some kind of firm, or unwavering &g...

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

...> >> >> +1 >> >> This canonicalization seems like it's unlikely to help other passes, and >> definitely makes handling more complicated elsewhere. >> >> >> -1 >> ;] >> >> I think it is very useful to be able to canonicalize on GEPs rather than >> bitcasts. >> >> >> Based on what? >> >> >> TBH, no hard data at all. Just my experience poking at passes that cared >> about this and the advice I received from others when hacking on them. >> Sorry if anything I wrote came off as...

...cond 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 (e.g., gep %a, 0, %i, %j) because it "smartly" recognizes ptx doesn't support any addressing mode that can fold this GEP (This addressing mode issue is worth another thread, and one of my colleagues is working on that). > > - To make this target inde...

...t hurts, then I would propose moving this logic to SROA and always canonicalize gep 0 to bitcast. +1 This canonicalization seems like it's unlikely to help other passes, and definitely makes handling more complicated elsewhere. -1 ;] I think it is very useful to be able to canonicalize on GEPs rather than bitcasts. Based on what? TBH, no hard data at all. Just my experience poking at passes that cared about this and the advice I received from others when hacking on them. Sorry if anything I wrote came off as some kind of firm, or unwavering position, it was more that I'm not sure...

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

...p 0 to bitcast. >> >> >> +1 >> >> This canonicalization seems like it's unlikely to help other passes, and >> definitely makes handling more complicated elsewhere. >> > > -1 > ;] > > I think it is very useful to be able to canonicalize on GEPs rather than > bitcasts. > Based on what? > I would teach things to understand GEPs with zero indices, it's pretty > easy (we have tools to automate it). > So your position is that we should teach literally everything to understand something new, instead of canonicalize in the...

...venance). 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 are many ways to encode the same GEP) and increases compile-time (optimizations need to constantly decompose GEPs, e.g. to get constant offsets). What am I missing here? Nikita, Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200713/28789b73/attachment.html>

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

...404 %X = bitcast i8* %OBJ to i32* %1 = load i32, i32* %X, align 4, !tbaa !2 %arrayidx = getelementptr inbounds i8, i8* %call, i64 540 %2 = bitcast i8* %arrayidx to i32* %3 = load i32, i32* %2, align 4, !tbaa !8 %add = add nsw i32 %3, %1 ret i32 %add } Instruction combiner transforms GEPs to i8 type, because of this the GEP offset looks weird and the actual type information is missing on GEP. I expected the GEPs to use the actual type offsetting for which the memory is allocated. Expected IR: ; Function Attrs: nounwind uwtable define i32 @foo(i32 %offset) local_unnamed_addr #0 { e...

...t it as promoting the > float elements. > > I would like to make it illegal to GEP into a vector as I think it is > cleaner and more consistent. Opinions? Comments? I agree that disallowing GEP from indexing into vector elements seems a little cleaner and more consistent. I have used GEPs to index into vectors once (in code not in the LLVM tree), but I'm pretty sure that code could be rewritten to avoid needing that. It's currently illegal to bitcast directly to or from an array type though, so the workaround for people who need to index into vector elements with a GEP is t...

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 =

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

...this logic to SROA > and always canonicalize gep 0 to bitcast. > > > +1 > > This canonicalization seems like it's unlikely to help other passes, and > definitely makes handling more complicated elsewhere. > -1 ;] I think it is very useful to be able to canonicalize on GEPs rather than bitcasts. I would teach things to understand GEPs with zero indices, it's pretty easy (we have tools to automate it). One reason why is that most things that want to reason about all-zero GEPs probably want to reason about all-constant GEPs as well. Certainly, I would expect MemDep...

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

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

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