search for: getunderlyingobjects

Hello all. I'm investigating a problem with "Machine Instruction Scheduling" that is rooted in incorrect alias information. Things go wrong in the "Merge disjoint stack slots"[1] pass when a store instruction fails to get updated after its stack slot is merged. As a result, when "Machine Instruction Scheduling" runs, it incorrectly re-orders the store and a

Hi Matthew, > I'm investigating a problem with "Machine Instruction Scheduling" that is rooted > in incorrect alias information. > > Things go wrong in the "Merge disjoint stack slots"[1] pass when a store > instruction fails to get updated after its stack slot is merged. As a result, > when "Machine Instruction Scheduling" runs, it incorrectly

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 GetUnderlyingObject and stop? ~Craig -------------- next part

Yep. Makes sense to me. There's nothing 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 >

Dan Gohman wrote: > On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > >> 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,

After discussing with Nick Lewycky in the IRC 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

Hans Wennborg wrote: > After discussing with Nick Lewycky in the IRC 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

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

Ok folks, I wrote up the general high-level thoughts I have about stateful AA in a separate thread. But we need to sort out the completely and horribly broken aspects of GlobalsModRef today, and the practical steps forward. This email is totally about the practical stuff. Now, as to why I emailed this group of people and with this subject, the only pass pipeline that includes GlobalsModRef, is

----- Original Message ----- > From: "Chris Lattner" <clattner at apple.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov>, "Justin Bogner" > <mail at justinbogner.com>, "Duncan Exon Smith"

On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > 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

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

On Mon, Jul 13, 2015 at 10:21 PM Chris Lattner <clattner at apple.com> wrote: > > > On Jul 13, 2015, at 8:19 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > > > > Ok folks, > > > > I wrote up the general high-level thoughts I have about stateful AA in a > separate thread. But we need to sort out the completely and horribly broken >

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

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

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

Dan Gohman wrote: > Hello, > > On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: >> >> / Hans >> Index: lib/Analysis/BasicAliasAnalysis.cpp >> =================================================================== >> --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) >> +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) >> @@ -633,6 +633,15

On 2/27/13 11:21 AM, Arnold Schwaighofer wrote: > On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> Hi, Nuno and Arnold: >> >> Thank you all for the input. >> >> Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. >> A clique is statically or dynamically allocated

Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult >