search for: getunderlyingobject

...sult, when "Machine Instruction Scheduling" runs, it incorrectly re-orders the store and a subsequent load, thinking that they do not refer to the same underlying object when they actually do. The logic in "Merge disjoint stack slots" seems ok, except that it relies on llvm::GetUnderlyingObject[2] to determine if an instruction needs to be updated. Unfortunately, unlike ScheduleDAGInstrs' getUnderlyingObject[3], llvm::GetUnderlyingObject doesn't handle ptrtoint instructions, and in this case, fails to see that the problematic store refers to the merged stack slot. It seems to...

...ine Instruction Scheduling" runs, it incorrectly re-orders the store > and a subsequent load, thinking that they do not refer to the same underlying > object when they actually do. > > The logic in "Merge disjoint stack slots" seems ok, except that it relies on > llvm::GetUnderlyingObject[2] to determine if an instruction needs to be updated. it sounds to me like this logic is broken. For example, GetUnderlyingObject has a recursion limit that will bail out if it has to look through too many instructions to find the underlying object. Thus you can't ever rely on GetUnderlying...

I notice that GetUnderlyingObject has a few checks, but alloca isn't one of them. Then it fall backs to SimplifyInstruction which doesn't know about alloca so falls back to just trying to constant fold it. This seems a little silly since I assume alloca can't be constant folded. Should we just detect this early in GetUn...

...g to simplify or constant-fold about an alloca. -Hal On 04/12/2017 04:23 PM, Craig Topper wrote: > Ping > > ~Craig > > On Fri, Apr 7, 2017 at 1:25 PM, Craig Topper <craig.topper at gmail.com > <mailto:craig.topper at gmail.com>> wrote: > > I notice that GetUnderlyingObject has a few checks, but alloca > isn't one of them. Then it fall backs to SimplifyInstruction which > doesn't know about alloca so falls back to just trying to constant > fold it. This seems a little silly since I assume alloca can't be > constant folded. Shoul...

...or>(V1)) >> + V1 = g->getOperand(0); >> + >> + if (const Argument *A = dyn_cast<Argument>(V1)) >> + if (A->hasNoAliasAttr()) >> + return NoAlias; >> + } > > The GEP logic here is effectively doing (a subset of) what > getUnderlyingObject does. It would be better to move these checks > below the getUnderlyingObject calls just below so that they can > use the results from those calls instead. > > And instead of checking for a no-alias argument, this code could > use isIdentifiedObject instead, following my comment abo...

...C channel, here comes a less aggressive patch. We were worried that a constant pointer could alias with a GlobalValue. Also, if one pointer could be a GlobalValue and the other a GlobalAlias with the GlobalValue as aliasee. However, I was not able to produce a test where this happens wihout the getUnderlyingObject() returning the same value. It would be nice if someone could produce such a test case, or dismiss the possibility of this happening. Anyway, saying that a Constant does not alias with a non-const isIdentifiedObject object seems safe. / Hans Hans Wennborg wrote: > Dan Gohman wrote: >&...

...aggressive patch. > > We were worried that a constant pointer could alias with a GlobalValue. > Also, if one pointer could be a GlobalValue and the other a GlobalAlias > with the GlobalValue as aliasee. > However, I was not able to produce a test where this happens wihout the > getUnderlyingObject() returning the same value. > > It would be nice if someone could produce such a test case, or dismiss > the possibility of this happening. My bad, it seems that while I wasn't looking, someone taught getUnderlyingObject to look through GlobalAliases and return what they point to!...

...lt;< **it <<"\n"); return false; } In the first pass, it registers all underlying objects for writes, than it does it again for reads, if the value was already there, it's a conflict. However, the read is from Foo.bl / Foo.cl and the write to Foo.al, so why is GetUnderlyingObjects() returning the same objects/pointers? A quick look at it revealed me the problem: llvm::GetUnderlyingObject(Value *V, const DataLayout *TD, unsigned MaxLookup) yields: -> GEPOperator *GEP = dyn_cast<GEPOperator>(V) -> V = GEP->getPointerOperand(); -> GlobalAlias *GA = dyn_cas...

...issues in its caches, etc. I plan to send out a patch soon that switches it over to this strategy. It is also relying on a precomputed set of global variables whose address is never used by an instruction other than some very small set (gep, bitcast) as "non-address-taken". It then runs GetUnderlyingObject on the two pointers in alias queries, and if that finds one of these "non-address-taken" globals for one of the memory locations but not the other, it concludes no-alias! This is broken for a number of reasons. a) If the two locations merely have a different *depth* of instruction stack,...

...Ah, so it is just an LTO enabled benchmark hack then. > > > It is also relying on a precomputed set of global variables whose > > address is never used by an instruction other than some very small > > set (gep, bitcast) as "non-address-taken". It then runs > > GetUnderlyingObject on the two pointers in alias queries, and if > > that finds one of these "non-address-taken" globals for one of the > > memory locations but not the other, it concludes no-alias! This is > > broken for a number of reasons. > > > > a) If the two locations mer...

...GEPOperator *g = dyn_cast<GEPOperator>(V1)) > + V1 = g->getOperand(0); > + > + if (const Argument *A = dyn_cast<Argument>(V1)) > + if (A->hasNoAliasAttr()) > + return NoAlias; > + } The GEP logic here is effectively doing (a subset of) what getUnderlyingObject does. It would be better to move these checks below the getUnderlyingObject calls just below so that they can use the results from those calls instead. And instead of checking for a no-alias argument, this code could use isIdentifiedObject instead, following my comment above. Dan > // Figur...

Here is another change I'd like to suggest to the BasicAliasAnalysis. LLVM fails to remove the dead store in the following code: %t = type { i32 } define void @f(%t* noalias nocapture %stuff ) { %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 store i32 1, i32* %p; <-- This store is dead %x = load i32* inttoptr (i32 12345 to i32*) store i32 %x, i32* %p ret

...O pipeline. > > Ah, so it is just an LTO enabled benchmark hack then. > > > It is also relying on a precomputed set of global variables whose > address is never used by an instruction other than some very small set > (gep, bitcast) as "non-address-taken". It then runs GetUnderlyingObject on > the two pointers in alias queries, and if that finds one of these > "non-address-taken" globals for one of the memory locations but not the > other, it concludes no-alias! This is broken for a number of reasons. > > > > a) If the two locations merely have a diffe...

...n"); > return false; > } > > In the first pass, it registers all underlying objects for writes, than it does it again for reads, if the value was already there, it's a conflict. > > However, the read is from Foo.bl / Foo.cl and the write to Foo.al, so why is GetUnderlyingObjects() returning the same objects/pointers? > > A quick look at it revealed me the problem: > > llvm::GetUnderlyingObject(Value *V, const DataLayout *TD, unsigned MaxLookup) yields: > > -> GEPOperator *GEP = dyn_cast<GEPOperator>(V) > -> V = GEP->getPointerOperand...

Replying here, but several of the questions raised boil down to "couldn't you make the usage of GetUnderlyingObject conservatively correct?". I'll try and address that. I think this *is* the right approach, but I think it is very hard to do without effectively disabling this part of GlobalsModRef. That is, the easy ways are likely to fire very frequently IMO. The core idea is to detect a "no info...

You can use the GetUnderlyingObjects function (notice the S at the end of the name) to collect zero or more underlying objects. This method is similar to GetUnderlyingObject except that it can look through phi and select instructions and return multiple objects. On Mar 14, 2013, at 4:15 AM, rahul <rahul3527 at gmail.com> wro...

Hi, I am writing a pass that works at machine level and runs as last pass in llc (just before converting llvm specific machine instructions into target specific instructions) In this pass I am trying to get underlying object for memory operations. It turns out that due to various optimizations on machine instructions, the memory operand in the operation is not always getelementptr (for e.g., it

...alue()) >> + return NoAlias; >> + > > As Chris mentioned, for consistency with what the rest of LLVM is doing, > this should check whether the pointers are in the default address space > (0). > > Also, this could be generalized by checking the results from > getUnderlyingObject, since it's not valid to do arithmetic from null to > reach an LLVM identified object either. I'm not sure what you mean by generalizing. Do you mean I should do the check on O1 and O2, which are the results of calls to getUnderlyingObject? Something like: if (const ConstantPointerNu...

...asserts that something can be assumed "no alias" if the access size of an memory access (i.e. a load or store) is bigger than the underlying object of the other accessed object. > > For you example below: > > V1Size = sizeof(mydata) > V2Size = say 4 > > assuming that GetUnderlyingObject for addr1 and addr2 returns mydata: This assumption is wrong. The GetUnderlyingObject() return phi node instead of &mydata. > > getObjectSize(O1) = sizeof(mydata) > getObjectSize(O2) = sizeof(mydata) > > this should be > isObjectSmallerThan(O2, V1Size) == false > isObject...

...nstant>(V2)) > + if (C->isNullValue()) > + return NoAlias; > + As Chris mentioned, for consistency with what the rest of LLVM is doing, this should check whether the pointers are in the default address space (0). Also, this could be generalized by checking the results from getUnderlyingObject, since it's not valid to do arithmetic from null to reach an LLVM identified object either. Dan