search for: underlyingobjectsalia

...ful dependence when the base pointer changes between loop iterations. In your case, it's done by a PHINode, but it could also be loaded from memory each iteration (and some metadata indicates that two loaded pointers does not alias IN THE SAME ITERATION). DI tries to approximate this: switch (underlyingObjectsAlias(AA, F->getParent()->getDataLayout(), MemoryLocation::get(Dst), MemoryLocation::get(Src))) { case MayAlias: case PartialAlias: // cannot analyse objects if we don't understand their aliasing. LLVM_DEBUG(dbgs() &...

As far Am Mi., 18. März 2020 um 11:34 Uhr schrieb Chawla, Pankaj <pankaj.chawla at intel.com>: > >> There seems to be a bug in DI, see Felipe's answer. > Maybe I missed something. There seems to be no resolution to the problem. How can DA fix this without help from alias analysis? DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another

...;s easy to see that the logic used in aliasSelect is valid, and that aliasPHI is returning the correct result for the given example. Maybe it's worth calling this out in the alias analysis documentation. +1 The flaw here seems to be in the way that DA is using AA. DependenceAnalysis's underlyingObjectsAlias is doing this:   // Check the original locations (minus size) for noalias, which can happen for   // tbaa, incompatible underlying object locations, etc.   MemoryLocation LocAS(LocA.Ptr, LocationSize::unknown(), LocA.AATags);   MemoryLocation LocBS(LocB.Ptr, LocationSize::unknown(), LocB.AATags);...

Alias analysis is figuring out the relationship between two pointer expressions, at some location in the program. At a given point in the program, do two expressions always refer to the same location? At a given point in the program, do two expressions never refer to the same location? AliasAnalysis::alias() doesn't explicitly take a "point" in the program because we don't