Implements ORE in AtomicExpandPass to report atomics generating a compare and swap loop.
arsenm yaxunl rampitec b-sumner t-tye nikic
- rGf22ba5187350: [Remarks] Emit optimization remarks for atomics generating CAS loop
rG435785214f73: [Remarks] Emit optimization remarks for atomics generating CAS loop
rGc4e5425aa579: [Remarks] Emit optimization remarks for atomics generating CAS loop
Compile time regressions especially for -O0 -g are higher than expected with this patch.
- changed type of ORE from OptimizationRemarkEmitter* to std::shared_ptr<OptimizationRemarkEmitter> and construct it within AtomicExpandPass, this solution is implemented to address for the regressions in many backends due to prerequisite passes
Still same problem with -O0 -g.
Please wait a bit for more people, dont rush.
The reason are the additional DominatorTree and LoopInfo calculations. These have a big impact at O0. These analysis calculations are caused by a deficiency in the legacy pass manager, which is still used for the codegen pipeline: Even though these analyses are only needed if diagnostic hotness is used, the pass manager requires them to be scheduled unconditionally.
The way to avoid this is to construct ORE without going through the pass manager. Grep for OptimizationRemarkEmitter ORE for various passes that already do this (though the reason is different in some cases -- there are some analysis preservation concerns with loop passes).
You also need to drop the getAnalysisUsage() change, otherwise the pass manager will still create the ORE itself.
PS: This revision still has incorrectly configured permissions, which prevents me from leaving line comments. Revisions on this Phabricator instance should always be publicly writable.
We can certainly implement it as a local variable as long as we have access to the function this pass is operating on. I was thinking of its potential use throughout this pass in the future.
You have access to the function, AI->getParent()->getParent().