<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 4, 2021 at 9:52 PM Björn Pettersson A <<a href="mailto:bjorn.a.pettersson@ericsson.com">bjorn.a.pettersson@ericsson.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi llvm-dev!<br>
<br>
By adding some checks that the dominator tree is correct in BasicAliasAnalysis and ValueTracking, such as below, a number of lit tests are failing.<br>
<br>
I stumbled upon this problem when analyzing some miscompiles for our OOT target, but I think this also indicates that there could be similar problems in-tree.<br>
<br>
<br>
Here are some examples of checks that I've played around with:<br>
<br>
<br>
diff --git a/llvm/lib/Analysis/BasicAliasAnalysis.cpp b/llvm/lib/Analysis/BasicAliasAnalysis.cpp<br>
index a0da8b7347ea..adb4b6908ada 100644<br>
--- a/llvm/lib/Analysis/BasicAliasAnalysis.cpp<br>
+++ b/llvm/lib/Analysis/BasicAliasAnalysis.cpp<br>
@@ -1099,6 +1099,8 @@ AliasResult BasicAAResult::aliasGEP(<br>
const GEPOperator *GEP1, LocationSize V1Size, const AAMDNodes &V1AAInfo,<br>
const Value *V2, LocationSize V2Size, const AAMDNodes &V2AAInfo,<br>
const Value *UnderlyingV1, const Value *UnderlyingV2, AAQueryInfo &AAQI) {<br>
+ if (DT)<br>
+ DT->verify();<br>
DecomposedGEP DecompGEP1 = DecomposeGEPExpression(GEP1, DL, &AC, DT);<br>
DecomposedGEP DecompGEP2 = DecomposeGEPExpression(V2, DL, &AC, DT);<br>
<br>
@@ -1699,6 +1701,8 @@ AliasResult BasicAAResult::aliasCheck(const Value *V1, LocationSize V1Size,<br>
/// noalias(V, phi(VA, VB)) if noalias(V, VA) and noalias(V, VB).<br>
bool BasicAAResult::isValueEqualInPotentialCycles(const Value *V,<br>
const Value *V2) {<br>
+ if (DT)<br>
+ DT->verify();<br>
if (V != V2)<br>
return false;<br>
<br>
diff --git a/llvm/lib/Analysis/ValueTracking.cpp b/llvm/lib/Analysis/ValueTracking.cpp<br>
index 303240d03c72..dc2918a0f895 100644<br>
--- a/llvm/lib/Analysis/ValueTracking.cpp<br>
+++ b/llvm/lib/Analysis/ValueTracking.cpp<br>
@@ -257,6 +257,8 @@ KnownBits llvm::computeKnownBits(const Value *V, const APInt &DemandedElts,<br>
const DominatorTree *DT,<br>
OptimizationRemarkEmitter *ORE,<br>
bool UseInstrInfo) {<br>
+ if (DT)<br>
+ DT->verify();<br>
return ::computeKnownBits(<br>
V, DemandedElts, Depth,<br>
Query(DL, AC, safeCxtI(V, CxtI), DT, UseInstrInfo, ORE));<br>
@@ -266,6 +268,8 @@ bool llvm::haveNoCommonBitsSet(const Value *LHS, const Value *RHS,<br>
const DataLayout &DL, AssumptionCache *AC,<br>
const Instruction *CxtI, const DominatorTree *DT,<br>
bool UseInstrInfo) {<br>
+ if (DT)<br>
+ DT->verify();<br>
assert(LHS->getType() == RHS->getType() &&<br>
"LHS and RHS should have the same type");<br>
assert(LHS->getType()->isIntOrIntVectorTy() &&<br>
@@ -393,6 +397,8 @@ unsigned llvm::ComputeNumSignBits(const Value *V, const DataLayout &DL,<br>
unsigned Depth, AssumptionCache *AC,<br>
const Instruction *CxtI,<br>
const DominatorTree *DT, bool UseInstrInfo) {<br>
+ if (DT)<br>
+ DT->verify();<br>
return ::ComputeNumSignBits(<br>
V, Depth, Query(DL, AC, safeCxtI(V, CxtI), DT, UseInstrInfo));<br>
}<br>
@@ -548,6 +554,8 @@ bool llvm::isAssumeLikeIntrinsic(const Instruction *I) {<br>
bool llvm::isValidAssumeForContext(const Instruction *Inv,<br>
const Instruction *CxtI,<br>
const DominatorTree *DT) {<br>
+ if (DT)<br>
+ DT->verify();<br>
// There are two restrictions on the use of an assume:<br>
// 1. The assume must dominate the context (or the control flow must<br>
// reach the assume whenever it reaches the context).<br>
@@ -2071,6 +2079,8 @@ static bool isGEPKnownNonNull(const GEPOperator *GEP, unsigned Depth,<br>
static bool isKnownNonNullFromDominatingCondition(const Value *V,<br>
const Instruction *CtxI,<br>
const DominatorTree *DT) {<br>
+ if (DT)<br>
+ DT->verify();<br>
if (isa<Constant>(V))<br>
return false;<br>
<br>
<br>
<br>
<br>
My current suspicion has been that the LegacyPassManager is calculating the "last user" incorrectly sometimes, ending up freeing the DominatorTree/BasicAliasAnalysis passes before the last use. If that is true, then it still is a bit scary that there are stale pointers (?) to an invalid BasicAA/DominatorTree being used later.<br>
<br>
One thing that strengthens the suspicion is that if we tell the pass manager that the chained analyses used by AliasAnalysis and BasicAliasAnalysis are "transitive", then the above problem with faulty DominatorTrees aren't seen any longer.<br>
<br>
Here is the patch I've played around with to make sure DT is correct:<br>
diff --git a/llvm/lib/Analysis/AliasAnalysis.cpp b/llvm/lib/Analysis/AliasAnalysis.cpp<br>
index f5b62ef06a23..fae7a84332fd 100644<br>
--- a/llvm/lib/Analysis/AliasAnalysis.cpp<br>
+++ b/llvm/lib/Analysis/AliasAnalysis.cpp<br>
@@ -883,8 +883,8 @@ bool AAResultsWrapperPass::runOnFunction(Function &F) {<br>
<br>
void AAResultsWrapperPass::getAnalysisUsage(AnalysisUsage &AU) const {<br>
AU.setPreservesAll();<br>
- AU.addRequired<BasicAAWrapperPass>();<br>
- AU.addRequired<TargetLibraryInfoWrapperPass>();<br>
+ AU.addRequiredTransitive<BasicAAWrapperPass>();<br>
+ AU.addRequiredTransitive<TargetLibraryInfoWrapperPass>();<br>
<br>
// We also need to mark all the alias analysis passes we will potentially<br>
// probe in runOnFunction as used here to ensure the legacy pass manager<br>
diff --git a/llvm/lib/Analysis/BasicAliasAnalysis.cpp b/llvm/lib/Analysis/BasicAliasAnalysis.cpp<br>
index f9275daf1224..a0da8b7347ea 100644<br>
--- a/llvm/lib/Analysis/BasicAliasAnalysis.cpp<br>
+++ b/llvm/lib/Analysis/BasicAliasAnalysis.cpp<br>
@@ -1875,9 +1875,9 @@ bool BasicAAWrapperPass::runOnFunction(Function &F) {<br>
<br>
void BasicAAWrapperPass::getAnalysisUsage(AnalysisUsage &AU) const {<br>
AU.setPreservesAll();<br>
- AU.addRequired<AssumptionCacheTracker>();<br>
- AU.addRequired<DominatorTreeWrapperPass>();<br>
- AU.addRequired<TargetLibraryInfoWrapperPass>();<br>
+ AU.addRequiredTransitive<AssumptionCacheTracker>();<br>
+ AU.addRequiredTransitive<DominatorTreeWrapperPass>();<br>
+ AU.addRequiredTransitive<TargetLibraryInfoWrapperPass>();<br>
AU.addUsedIfAvailable<PhiValuesWrapperPass>();<br>
}<br>
<br>
<br>
<br>
<br>
There is however some problems with such a fix. Because then the following tests hits assertions when setting up the pipeline:<br>
LLVM :: CodeGen/Hexagon/bug15515-shuffle.ll<br>
LLVM :: CodeGen/Hexagon/const-pool-tf.ll<br>
LLVM :: CodeGen/Hexagon/glob-align-volatile.ll<br>
LLVM :: CodeGen/Hexagon/loop-idiom/lcssa.ll<br>
LLVM :: CodeGen/Hexagon/loop-idiom/pmpy-mod.ll<br>
LLVM :: Transforms/GVNHoist/hoist-mssa.ll<br>
LLVM :: Transforms/GVNHoist/hoist-newgvn.ll<br>
LLVM :: Transforms/GVNHoist/hoist-pr20242.ll<br>
LLVM :: Transforms/GVNHoist/hoist-pr28933.ll<br>
LLVM :: Transforms/GVNHoist/hoist-recursive-geps.ll<br>
LLVM :: Transforms/SimplifyCFG/Hexagon/disable-lookup-table.ll<br>
LLVM :: Transforms/SimplifyCFG/Hexagon/switch-to-lookup-table.ll<br>
<br>
<br>
So maybe addRequiredTransitive isn't supposed to be used like that?<br>
<br>
Or there is something bad with GVNHoist and Hexagon?<br>
<br>
<br>
I haven't looked any closer at Hexagon, but looked a bit at GVNHoist without really finding anything weird (comparing it with other passes that require AAResults). The assert can be seen if applying the patch above and then running<br>
<br>
opt -gvn-hoist -gvn-hoist -S /dev/null<br>
<br>
and it says<br>
<br>
opt: ../lib/IR/LegacyPassManager.cpp:607: void llvm::PMTopLevelManager::setLastUser(ArrayRef<llvm::Pass *>, llvm::Pass *): Assertion `AnalysisPass && "Expected analysis pass to exist."' failed.<br>
<br>
<br>
Afaict the pass that it fails to find is 'Basic Alias Analysis (stateless AA impl)'. But I do not understand why.<br>
<br>
<br>
<br>
Anyone who knows more about addRequiredTransitive, or how one is supposed to tell the pass manager about nested analysis pass/group dependencies?<br>
<br>
<br>
PS. This problem has been mentioned a bit in <a href="https://reviews.llvm.org/rGb21840751278128ef6942074ae89ea63c9c6ac58" rel="noreferrer" target="_blank">https://reviews.llvm.org/rGb21840751278128ef6942074ae89ea63c9c6ac58</a> , as we started to see miscompiles after that commit and after <a href="https://reviews.llvm.org/rGa3614a31c46a41b76fd6a6c6b30b353bc4131b94" rel="noreferrer" target="_blank">https://reviews.llvm.org/rGa3614a31c46a41b76fd6a6c6b30b353bc4131b94</a> . Those commits seem to have exposed the problem with faulty dominator trees a bit more after adding more usage of the sometimes faulty DT.<br></blockquote><div><br></div><div>I'm not familiar enough with the pass manager to say something meaningful here, but the addRequiredTransitive() issue sounds similar to what is discussed in <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-November/146923.html">https://lists.llvm.org/pipermail/llvm-dev/2020-November/146923.html</a>.</div><div><br></div><div>Regards,<br></div><div>Nikita<br> </div></div></div>