They can already be available, and even if not, DT/LI can be available. We should not recompute them.
Old PM is unchanged because it would require changing dependencies, and we don't care enough about it.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
My measurements are tad noisy, but they show ~10% JumpThreading CT saving on a big method.
llvm/lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
327 | You'd have to also register it with AnalysisUses and initialize a pass dependency. I'd suggest to leave the LegacyPM implementation alone. |
llvm/lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
353–355 | can these two also go through the analysis manager? |
llvm/lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
327 | You're right. |
This change has caused our internal PGO+NewPM builds of clang to have become non-reproducible (that is: the binary is different every build, when built with a Clang that includes this change). The problem appears only when providing profile data. I am not sure why this change causes a problem -- perhaps some of the analysis data ought to have been invalidated by some other pass, but wasn't?
But, I've bisected to exactly this commit, so, I'm going to revert it while continuing to investigate.
Hi! Any update on this?
Not sure if it has any impact on your case but there is a chance that JumpThreading updates profile metadata through updatePredecessorProfileMetadata and doesn't invalidate BPI/BFI analysis.
You'd have to also register it with AnalysisUses and initialize a pass dependency. I'd suggest to leave the LegacyPM implementation alone.