similar to: (BasicAA) PartialAlias between different fields of a structure, intentional?

Hi, We've seen a similar case recently, where BasicAA returns PartialAlias for the access of two different fields of a structure. We noticed this since Lint complained about it when checking for aliasing beteen "noalias" attributed parameters: opt -S -lint ./alias.ll gave Unusual: noalias argument aliases another argument on the (silly) function: %rec7 = type { i16, i16, i16

Hi, I going through the alias analysis documentation (http://llvm.org/docs/AliasAnalysis.html) and noticed the following in the definition of PartialAlias: " The PartialAlias response is used when the two memory objects are known to be overlapping in some way, but *do not start at the same address*. " Is it really required that the objects do no start at the same address? if

Thank you all for your replies. So here seems to be an agreement that the documentation for PartialAlias is incorrect. Daniel: now you got me wondering about MustAlias. This is what the docs say: "The MustAlias response may only be returned if the two memory objects are *guaranteed to always start at exactly the same location*" This statement is regardless of the access sizes. For

On 07/14/2017 03:00 PM, Davide Italiano via llvm-dev wrote: > On Fri, Jul 14, 2017 at 12:50 PM, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> I going through the alias analysis documentation >> (http://llvm.org/docs/AliasAnalysis.html) and noticed the following in the >> definition of PartialAlias: >> " >> The

On Sat, Jul 15, 2017 at 5:35 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >>> >>>> Thank you all for your replies. >>>> So here seems to be an agreement that the documentation for >>>> PartialAlias is incorrect. >>>>

On Sun, Jul 16, 2017 at 2:34 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes wrote: >>> >>>> On 07/15/2017 04:51 AM, Nuno Lopes wrote: >>>> >>>>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >>>>>> >>>>>>> Thank you all for your replies.

> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >> Thank you all for your replies. >> So here seems to be an agreement that the documentation for PartialAlias >> is incorrect. >> >> Daniel: now you got me wondering about MustAlias. This is what the docs >> say: >> "The MustAlias response may only be returned if the two memory objects >> are

On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > >On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: > >>>> Thank you all for your replies. > >>>> So here seems to be an agreement that the documentation for > >>>> PartialAlias is incorrect. > >>>>

Updated testcases to have MayAlias/note issues as FIXME. On Tue Jan 20 2015 at 3:54:10 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Daniel Berlin" <dberlin at dberlin.org> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "George

On Wed Jan 21 2015 at 12:30:50 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Daniel Berlin" <dberlin at dberlin.org> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "George Burgess IV" < > george.burgess.iv at gmail.com>,

So, I can make all these testcases work, but it's a little tricky (it involves tracking some things, like GEP byte range, and then checking bases and using getObjectSize, much like BasicAA does). Because i really don't want to put that much "not well tested" code in a bugfix, and honestly, i'm not sure we will catch any cases here that BasicAA does not, i've attached a

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "George Burgess IV" <george.burgess.iv at gmail.com>, "LLVM Developers > Mailing List" <llvmdev at cs.uiuc.edu>, "Nick Lewycky"

> Should we be added an edge from the inttoptr to all other pointer values? Is there a better way? We can add a special "Unknown" StratifiedAttr and query it before anything else, i.e: // in CFLAliasAnalysis::query, as the first potential return if (AttrsA[AttrUnknown] || AttrsB[AttrUnknown]) return MayAlias; The only *potential* issue with this approach would be that in the

Here is the result of running mem2reg then basicaa, it is even worse: (%a should be alias to %0, and partial alias to %3) opt -mem2reg -basicaa -aa-eval -print-all-alias-modref-info < foo.s > /dev/null Function: foo: 6 pointers, 0 call sites NoAlias: i32* %a, i32* %b NoAlias: i32* %a, i32* %c NoAlias: i32* %b, i32* %c PartialAlias: i32* %1, i32* %a NoAlias:

I’m checking aliasing of two pointers: %GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 1, i64 %indvars.iv41, i64 %indvars.iv39 %GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 16 The result I got is “PartialAlias” because the indices of the GEP1 are variable. That seems like a bug. PartialAlias should only be returned when we can prove a partial

Works for me On Thu, Jan 22, 2015 at 8:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > We should use graph edges, so we can do something better at set build time > :) > > > On Thu Jan 22 2015 at 5:20:46 PM George Burgess IV < > george.burgess.iv at gmail.com> wrote: > >> > Should we be added an edge from the inttoptr to all other pointer >>

On Fri, Sep 21, 2012 at 3:08 PM, Welson Sun <welson.sun at gmail.com> wrote: > OK, with the restrict type qualifier, it is a little bit better: > > The IR's function signature becomes: > define void @foo(i32* noalias %a, i32* noalias %b, i32* noalias %c) nounwind > { > > Now the AA result: > Function: foo: 13 pointers, 0 call sites > NoAlias: i32* %a,

Yes. I've attached an updated patch that does the following: 1. Fixes the partialalias of globals/arguments 2. Enables partialalias for cases where nothing has been unified to a global/argument 3. Fixes that select was unifying the condition to the other pieces (the condition does not need to be processed :P). This was causing unnecessary aliasing. 4. Adds a regression test to

Hi Danny, // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that // BasicAliasAnalysis wins if they disagree. This is intended to help // support "obvious" type-punning idioms. - if (UseCFLAA) - addPass(createCFLAliasAnalysisPass()); addPass(createTypeBasedAliasAnalysisPass()); addPass(createScopedNoAliasAAPass()); + if (UseCFLAA) +

Without the patch is also returns the wrong answer for all of these, it just doesn't cause LICM to promote because it returns PartialAlias (which is still wrong). We return may-alias instead, and now suddenly it's happy to promote them. The broken noalias results exist both before and after my patch: ===== Alias Analysis Evaluator Report ===== 521 Total Alias Queries Performed