[PATCH] D23738: [PM] Extend the explicit 'invalidate' method API on analysis results to accept an Invalidator that allows them to invalidate themselves if their dependencies are in turn invalidated.
Justin Lebar via llvm-commits
llvm-commits at lists.llvm.org
Sun Oct 9 21:46:14 PDT 2016
jlebar added inline comments.
================
Comment at: include/llvm/IR/PassManager.h:610
+ IMapI->second = Result.invalidate(IR, PA, Inv);
+ }
+
----------------
WRT the names:
I agree "invalidate" isn't a great name, because
if (!my_pass->invalidate(...)) {
// my_pass was not invalidated!
}
`checkIfInvalidated`? `onIRChange`? `notifyIRChanged`? I like the first one because the bool return value sort of makes sense.
This would also change the comment above -- we're not really "trying" to invalidate the result. More informing it that something has changed, and giving it the option to mark itself as invalid.
I still don't really understand what we're supposed to do inside the `invalidate` function, so I'm not sure about the `Invalidator` class name. The only example I have is
bool TestIndirectFunctionAnalysis::invalidate(Function &F, const PreservedAnalyses &PA,
FunctionAnalysisManager::Invalidator &Inv) {
return !PA.preserved<TestIndirectFunctionAnalysis>() ||
Inv.invalidate<TestFunctionAnalysis>(F, PA);
}
It naively seems to me that it would be better to structure things so that we never run this function if PA.preserved<TestIndirectFunctionAnalysis>(). The Invalidator could ensure this. Then our function could be
bool checkIfInvalidated(...) {
return Inv.checkIfInvalidated<Dep1>() || Inv.checkIfInvalidated<Dep2>();
}
which actually makes sense to me. I think ideally Inv.checkIfInvalidated would take zero parameters, since it's just boilerplate, but maybe it should still take the Function/Module/whatever. We'd at least be able to get rid of the PreservedAnalyses argument, I think?
https://reviews.llvm.org/D23738
More information about the llvm-commits
mailing list