search for: basicaaresult

...sSet[0x4a1e3a0, 3] may alias, Mod/Ref   Pointers: (i8* %11, 1), (i8* %10, 1), (i8* %16, 1)   AliasSet[0x4a1e440, 1] must alias, Mod        forwarding to 0x4a1e3a0 Alias analysis returns 'May- alias' for above code. When I look at the alias analysis code, below code causes may-alias. On BasicAAResult::aliasGEP() 1297     // Check to see if these two pointers are related by the getelementptr 1298     // instruction.  If one pointer is a GEP with a non-zero index of the other 1299     // pointer, we know they cannot alias. 1300 1301     // If both accesses are unknown size, we can't do any...

...(i8, i8* getelementptr inbounds ([2147483656 x i8], [2147483656 x i8]* @obj, i32 0, i32 0), i32 -2147483648), align 1 ret i8 %1 } With -O2, the store to q gets forwarded, and so we get "ret i8 1". So, BasicAA concluded that p and q don't alias. The culprit is an overflow in BasicAAResult::isGEPBaseAtNegativeOffset(). So my question is do we care about this use case where a single allocation can take more than half of the address space? Thanks, Nuno

...gt; > Does changing this condition fix the issue? E.g > > if (C1 && C2 && C1->getSExtValue() == C2->getSExtValue()) { ... } Yes it does. Then it realize the two GEPs alias and I get the expected result. But since there is also a Value pointer comparison in bool BasicAAResult::isValueEqualInPotentialCycles(const Value *V, const Value *V2) { if (V != V2) return false; and probably in several other places too I wasn't comfortable just changing it... Right now I made my front-end always use i64 for GEP array...

...for several functions, but llvm crashes at a certain point. I am checking dependencies between various loops in a function in that pass. The crash message and stack dump is: clang-9: /media/kiit/3E9AF7519AF703E5/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp:823: llvm::AliasResult llvm::BasicAAResult::alias(const llvm::MemoryLocation&, const llvm::MemoryLocation&, llvm::AAQueryInfo&): Assertion `notDifferentParent(LocA.Ptr, LocB.Ptr) && "BasicAliasAnalysis doesn't support interprocedural queries."' failed. Stack dump: 0. Program arguments: /media/kiit/3E9AF...

...it seems the reason for this is that the alias analysis considers the two pointers used to store and load the value 98 are non-aliasing, even if both the pointer and the indices has the same values. The only difference is the type of the last value. In e.g. BasicAliasAnalysis.cpp we have bool BasicAAResult::isValueEqualInPotentialCycles(const Value *V, const Value *V2) { if (V != V2) return false; and in aliasSameBasePointerGEPs: // If the last (struct) indices are constants and are equal, the other indices // might be also be dynam...

...019 2:29 PM To: De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan at intel.com> Cc: llvm-dev at lists.llvm.org; Finkel, Hal J. <hfinkel at anl.gov> Subject: Re: [llvm-dev] Question about a AA result and its use in Dependence Analysis Hi Felipe, (+ Hal) I think the reasoning in `BasicAAResult::aliasPHI(...)` is flawed but I want someone else to take a look as well. As far as I can tell, the reasoning there is as follows: - Two phi nodes in the same block do not alias by default. - They do alias if the pair of inputs from the same predecessor alias. - If all inputs are pair-wise a...

...47483656 x i8]* @obj, i32 0, i32 0), >> i32 -2147483648), align 1 >> ret i8 %1 >> } >> >> With -O2, the store to q gets forwarded, and so we get "ret i8 1". >> So, BasicAA concluded that p and q don't alias. The culprit is an >> overflow in BasicAAResult::isGEPBaseAtNegativeOffset(). >> >> So my question is do we care about this use case where a single >> allocation can take more than half of the address space? >> >> Thanks, >> Nuno

My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption that the PHIs are // NoAlias. // If the PHIs are May/MustAlias there must be (recursively) an input // operand from outside the PHIs' cycle that is MayAlias/MustAlias or // the...

...2019 9:04 AM > To: De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan at intel.com> > Cc: llvm-dev at lists.llvm.org > Subject: [EXT] Re: [llvm-dev] Question about a AA result and its use in > Dependence Analysis > > Thanks for investigating this further. > > In BasicAAResult::aliasSelect the "same" logic is used: > > // If the values are Selects with the same condition, we can do a more precise > // check: just check for aliases between the values on corresponding arms. > > That is what happens for PHI nodes as well. So, if either is...

...t find any usage that requires sizes to match. Actually most clients check access sizes themselves. Most don't need equal sizes, just need one to be smaller than the other. BTW, Basic AA doesn't check for size either: if (isValueEqualInPotentialCycles(V1, V2)) return MustAlias; bool BasicAAResult::isValueEqualInPotentialCycles(const Value *V, const Value *V2) { if (V != V2) return false; const Instruction *Inst = dyn_cast<Instruction>(V); if (!Inst) return true; (...) } So if V1==V2, BasicAA will yield MustAlias. I cou...

...r? My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption that the PHIs are // NoAlias. // If the PHIs are May/MustAlias there must be (recursively) an input // operand from outside the PHIs' cycle that is MayAlias/MustAlias or /...

...nnes via llvm-dev Sent: Monday, June 3, 2019 9:04 AM To: De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan at intel.com> Cc: llvm-dev at lists.llvm.org Subject: [EXT] Re: [llvm-dev] Question about a AA result and its use in Dependence Analysis Thanks for investigating this further. In BasicAAResult::aliasSelect the "same" logic is used: // If the values are Selects with the same condition, we can do a more precise // check: just check for aliases between the values on corresponding arms. That is what happens for PHI nodes as well. So, if either is broken both are. Now it r...

...7483656 x i8]* @obj, i32 0, i32 0), >> i32 -2147483648), align 1 >> ret i8 %1 >> } >> >> With -O2, the store to q gets forwarded, and so we get "ret i8 1". >> So, BasicAA concluded that p and q don't alias. The culprit is an >> overflow in BasicAAResult::isGEPBaseAtNegativeOffset(). >> >> So my question is do we care about this use case where a single >> allocation can take more than half of the address space? >> > > Accoding to LangRef, your IR currently has undefined behavior: the rules > for "inbounds&quo...

Hi Johannes, I followed your advice and got the same result: NoAlias and No dependence. Would you say AA is faulty for saying NoAlias or DA is faulty for saying no dependence? Or both? (revised example below) Thanks! define float @f() { entry: %g = alloca float, align 4 %h = alloca float, align 4 br label %for.body for.cond.cleanup: ; preds = %for.body

Hi all, I have this test case- #define N 1000 extern double Ag[N]; extern double Bg[N]; void consume(double *A, double *B); void swap_deps() { double *A = Ag; double *B = Bg; for (int i = 0; i < 97; ++i) { for (int j = 0; j < N; ++j) { B[j] = A[j] + 1; } double *tmp = A; A = B; B = tmp; } consume(A, B); } BasicAA is returning 'NoAlias' when

...? My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption that the PHIs are // NoAlias. // If the PHIs are May/MustAlias there must be (recursively) an input // operand from outside the PHIs' cycle that is MayAlias/MustAlias or /...

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