search for: partialalias

Hello all, I observed that BasicAA alias query returns PartialAlias between different fields of a structure. Following is the test program and -print–all-alias-modref-info output: --- ; test.ll target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %"type" = type { [10 x i32], i64 } d...

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

...e: > 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 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 >> th...

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 that's the case the AA algorithm would need to prove that....

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

...;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 change to XFAIL these testcases, and updated the code to return MayAlias. I will build and test a patch to get these back to PartialAlias, but this patch will at least get us to not be "giving wrong answers". I will also see if we catch anything with it that BasicAA does not, because if we don't, it doesn't seem worth it to me. Conservative new patch attached. (Note that i still updated the testcases, because we...

...cases here > > that BasicAA does not, i've attached a change to XFAIL these > > testcases, and updated the code to return MayAlias. > > Okay. I think you might as well just update the test cases to want > MayAlias, and put a FIXME comment explaining that they could be > PartialAlias. As far as I know, there is no code in LLVM that really > handles a PartialAlias differently than a MayAlias or MustAlias, and so > while there may be some benefit here, I'm not sure it will be worth the > effort. > > > > > I will build and test a patch to get these back...

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

...lias, then we'd cut out unecessary CFL queries). Perhaps this is > an irrelevant effect, but we should have some documented rationale. > > > > Yeah, this was a mistake (Chandler had suggested it was right > earlier, but we were both wrong :P) > > > > ; CHECK: PartialAlias: i16* %bigbase0, i8* %phi > -define i8 @test0(i8* %base, i1 %x) { > +define i8 @test0(i1 %x) { > entry: > + %base = alloca i8, align 4 > %baseplusone = getelementptr i8* %base, i64 1 > br i1 %x, label %red, label %green > red: > @@ -25,8 +26,9 @@ green: > } > > why...

...t; > Okay, thanks! This LGTM, but we should probably split the delegation fixes > from the others and commit as two separate patches (especially because Ana > noted some potential miscompiles caused by the other improvements). > I think she mentioned the miscompiles due to us returning partialalias. But in any case, i'm happy to, but just to note they are all required to get the LICM issue fixed :) > > Regarding this: > > @@ -768,7 +774,10 @@ static Optional<StratifiedAttr> > valueToAttrIndex(Value *Val) { > return AttrGlobalIndex; > > if (auto *Arg...

...TM, but we should probably split the delegation > fixes from the others and commit as two separate patches (especially > because Ana noted some potential miscompiles caused by the other > improvements). > > > > I think she mentioned the miscompiles due to us returning > partialalias. But in any case, i 'm happy to, but just to note they > are all required to get the LICM issue fixed :) > > > Okay, please do that and commit them. > > > > > Regarding this: > > @@ -768,7 +774,10 @@ static Optional<StratifiedAttr> > valueToAttrInde...

...i32* %i > MayAlias: i32* %3, i32* %a > MayAlias: i32* %3, i32* %b > MayAlias: i32* %3, i32* %c > NoAlias: i32* %3, i32** %a_addr > NoAlias: i32* %3, i32** %b_addr > NoAlias: i32* %3, i32** %c_addr > NoAlias: i32* %3, i32* %i > PartialAlias: i32* %0, i32* %3 > MayAlias: i32* %5, i32* %a > MayAlias: i32* %5, i32* %b > MayAlias: i32* %5, i32* %c > NoAlias: i32* %5, i32** %a_addr > NoAlias: i32* %5, i32** %b_addr > NoAlias: i32* %5, i32** %c_addr > NoAlias: i32* %5, i32*...

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

> 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 *guaranteed to always start at exactly the same location*" >&gt...

..., 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: i32* %1, i32* %b NoAlias: i32* %1, i32* %c NoAlias: i32* %4, i32* %a PartialAlias: i32* %4, i32* %b NoAlias: i32* %4, i32* %c NoAlias: i32* %1, i32* %4 NoAlias: i32* %8, i32* %a NoAlias: i32* %8, i32* %b PartialAlias: i...

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 overlap. Otherwise, MayAlias should be returned. [Demikhovsky, Elena] There are some comments inside: // Statically, we can see that the base objects are the same...

...the compile-time would be better (guessing that the metadata queries would be faster than the CFL queries, so if the metadata could quickly return a NoAlias, then we'd cut out unecessary CFL queries). Perhaps this is an irrelevant effect, but we should have some documented rationale. ; CHECK: PartialAlias: i16* %bigbase0, i8* %phi -define i8 @test0(i8* %base, i1 %x) { +define i8 @test0(i1 %x) { entry: + %base = alloca i8, align 4 %baseplusone = getelementptr i8* %base, i64 1 br i1 %x, label %red, label %green red: @@ -25,8 +26,9 @@ green: } why should this return PartialAlias? %ohi does...

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

...xes from the others and commit as two separate patches (especially >>> because Ana noted some potential miscompiles caused by the other >>> improvements). >>> >>> >>> >>> I think she mentioned the miscompiles due to us returning >>> partialalias. But in any case, i 'm happy to, but just to note they >>> are all required to get the LICM issue fixed :) >>> >>> >>> Okay, please do that and commit them. >>> >>> >>> >>> >>> Regarding this: >>> >&g...

Hi, 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. Shouldn't the "inbounds" keyword mean that the access to sub-array is also in-bounds? I'm trying to reach "NoAlias" consensus between GEP1 and GEP2. Thanks. - Elena ------------------------------------------...