-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Clean up strange uses of getAnalysisIfAvailable #65729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -935,7 +935,7 @@ bool AArch64ConditionalCompares::runOnMachineFunction(MachineFunction &MF) { | |
SchedModel = MF.getSubtarget().getSchedModel(); | ||
MRI = &MF.getRegInfo(); | ||
DomTree = &getAnalysis<MachineDominatorTree>(); | ||
Loops = getAnalysisIfAvailable<MachineLoopInfo>(); | ||
Loops = &getAnalysis<MachineLoopInfo>(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think there are some "weird" things going on here. But maybe not worth digging into those unless being an AArch64 maintainer. Afaict the goal here is to make sure MachineLoopInfo is preserved. So this pass shouldn't really need to require it explicitly. However, the MachineTraceMetrics pass is also using MachineLoopInfo transitively. So, the MachineLoopInfo analysis will be run. Although I think there is a "bug" in MachineTraceMetrics related to not using addRequiredTransitive. So things might break if removing the addRequired in this pass. To sum up. The proposed change is probably harmless and OK. Just saying that the analysis pass dependencies used in here seem to be a bit ad-hoc(?). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Everything seems to work if I change |
||
MBPI = &getAnalysis<MachineBranchProbabilityInfo>(); | ||
Traces = &getAnalysis<MachineTraceMetrics>(); | ||
MinInstr = nullptr; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3286,7 +3286,7 @@ class llvm::gvn::GVNLegacyPass : public FunctionPass { | |
if (skipFunction(F)) | ||
return false; | ||
|
||
auto *LIWP = getAnalysisIfAvailable<LoopInfoWrapperPass>(); | ||
auto &LIWP = getAnalysis<LoopInfoWrapperPass>(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IIUC GVN doesn't depend on LoopInfo itself. It should just make sure to preserve it if it is available. So one might wonder if it is the addRequire that should be questioned and possibly removed instead. Therefore I think you proposed change is ok. Or you could just leave this as is, since the IfAvailable part in some sense indicate that the pass itself doesn't depend on the analysis. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer not to leave it as is - I think either we should get the analysis with |
||
|
||
auto *MSSAWP = getAnalysisIfAvailable<MemorySSAWrapperPass>(); | ||
return Impl.runImpl( | ||
|
@@ -3297,7 +3297,7 @@ class llvm::gvn::GVNLegacyPass : public FunctionPass { | |
Impl.isMemDepEnabled() | ||
? &getAnalysis<MemoryDependenceWrapperPass>().getMemDep() | ||
: nullptr, | ||
LIWP ? &LIWP->getLoopInfo() : nullptr, | ||
&LIWP.getLoopInfo(), | ||
&getAnalysis<OptimizationRemarkEmitterWrapperPass>().getORE(), | ||
MSSAWP ? &MSSAWP->getMSSA() : nullptr); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how to add a comment on line 278 if I want to suggest an edit on that line (in Phabricator it would have been easy). But I guess the check if DebugVars is null or not on line 278 is redundant now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Fixed in 05c16f4