similar to: RFC: inbounds on getelementptr indices for global splitting

On Mon, May 4, 2015 at 9:40 AM, Nicholas White <n.j.white at gmail.com> wrote: > Thanks - that makes sense. It's interesting that at -O3 the optimizer > can't reduce the below though - I'll dig into it a bit and see if I > can make a patch that fixes it: I'm unsure what you expect to happen below. It's not quite the same testcase. GVN will PRE the loads, so you

Hi all, For loads and stores i want to extract information about the number of indices accessed. For instance: struct S {int X, int *Y}; __global__ void kernel(int *A, int **B, struct S) {   int x = A[..][..]; // -> L: A[..][..]   int y = *B[2];   // -> L: B[0][2]   int z = S.y[..];  // -> L: S.1[..]   // etc.. } I am performing some preprocessing on IR to: 1. Move constant

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

Michael makes a great point about aliasing here and different indexing that accesses the same element! Another note: x = A[0][2] is fundamentally different depending on the type of `A`. If e.g. A was declared: int A[10][20], there's only _one_ load. A is a (and is treated as) a linear buffer, and GEPs only pinpoint the specific position of A[0][2] in this buffer (i.e. 0*10 + 2). But if A was

Hi Ees, SCEV Delinearization is the closest I know. But it has its problems. Well for one your expression should be SCEVable. But more importantly, SCEV Delinearization is trying to deduce something that is high-level (actually source-level) from a low-level IR in which a lot of this info has been lost. So, since there's not a 1-1 mapping from high-level code to LLVM IR, going backwards will

Hi, I want to print the memory locations computed by getelementptr. As I understood, getelementptr does not access the memory, but it contains the address it computes. I want to print these addresses at runtime (or process them). So, I try to build a function that takes as argument a pointer and prints its value. And to call this function, by sending the gep instruction as a parameter.

Hi Bruce, On 25.02.19 13:10, Bruce Hoult wrote: > LLVM has no idea whether the address computed by GEP is actually > within a legal object. The "inbounds" keyword is just you, the > programmer, promising LLVM that you know it's ok and that you don't > care what happens if it is actually out of bounds. > >

Hi all, What exactly are the rules for `getelementptr inbounds` with offset 0? In Rust, we are relying on the fact that if we use, for example, `inttoptr` to turn `4` into a pointer, we can then do `getelementptr inbounds` with offset 0 on that without LLVM deducing that there actually is any dereferencable memory at location 4. The argument is that we can think of there being a zero-sized

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 Johannes, > From the Lang-Ref statement > > "With the inbounds keyword, the result value of the GEP is undefined > if the address is outside the actual underlying allocated object and > not the address one-past-the-end." > > I'd argue that the actual offset value (here 0) is irrelevant. The GEP > value is undefined if inbounds is present and the

Hi Johannes, >> So, the thinking here is: LLVM cannot exclude the possibility of an >> object of size 0 existing at any given address. The pointer returned >> by "GEPi p 0" then would be one-past-the-end of such a 0-sized object. >> Thus, "GEPi p 0" is the identitiy function for any p, it will not >> return poison. > > I don't see the

On 7/20/11 10:02 AM, Jimborean Alexandra wrote: > Hi, > > I want to print the memory locations computed by getelementptr. As I > understood, getelementptr does not access the memory, but it contains > the address it computes. I want to print these addresses at runtime > (or process them). So, I try to build a function that takes as > argument a pointer and prints its

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

Hi, all I am a LLVM user. I want to get every element in the next instruction: %0 = load i32* getelementptr inbounds (%struct.Args* @globalArg, i64 0, i32 2), align 4, !dbg !85, !clap !86 Now I can only get value "i32* getelementptr inbounds (%struct.Args* @globalArg, i64 0, i32 2)" through "getOperand(0)", but I can not get "%struct.Args* @globalArg", "i64

Given 2 GEPs as follows, %tmp124 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5, !dbg !1051 ; <[2 x i16]*> [#uses=1] %tmp125 = getelementptr inbounds [2 x i16]* %tmp124, i64 0, i64 0, !dbg !1051 ; <i16*> [#uses=1] can I replace the 2nd one with %tmp126 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5, i64 0, i64 0 ; <i16*> When I try to

On Sat, Nov 22, 2014 at 11:09 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Qiuping, > > If I'm reading the IR correctly, what you have is a > GetElementPtrConstantExpr [1]. It subclasses from llvm::Constant. > If you want the same code to handle GetElementPtrConstantExpr *and* GetElementPtrInst, you can use GEPOperator. > > Thanks, > --

Hi Michael, Thank you very much. But idx_begin/idx_end iterators can only be used through a getelementptr instruction, right? However, I think value "i32* getelementptr inbounds (%struct.Args* @globalArg, i64 0, i32 2)" itself is not a getelementptr instruction, so? Or could you tell me how can I get a getelementptr instruction first from this value?

I can't upload my program due to confidentiality, but the problem is obvious. At lib/Analysis/ConstantFolding.cpp:646 Constant *C = ConstantExpr::getGetElementPtr(Ops[0], NewIdxs); if (ConstantExpr *CE = dyn_cast<ConstantExpr>(C)) { if (Constant *Folded = ConstantFoldConstantExpression(CE, TD, TLI)) C = Folded; } The generated ConstantExpr C doesn't inherit the

Hi Johannes, > Now that reasoning works from a conceptual standpoint only for > non-inbounds GEPs, I think. From a practical standpoint my above > description will probably make sure everything works out just fine (see > also my rephrased answer down below!). I say this because I think the > following lang-ref passage makes sure everything, not only memory > accesses, involving

Hey, Considering the following instruction: %20 = load %struct.Node** getelementptr inbounds (%struct.Node* @head, i32 0, i32 0), align 16 ; <%struct.Node*> [#uses=1] What is the type of the first operand of the instruction (i.e., getOperand(0))? I thought the operand is a "GetElementPtr" instruction, however, the predicate "isa<Instruction>()" over