[llvm] [CodeLayout] Do not flip branch condition when using optsize (PR #114607)
Ellis Hoag via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 1 15:47:15 PDT 2024
ellishg wrote:
> Interesting, by this logic a simpler thing to do would probably be to ignore the whole `MachineBranchProbabilityInfo` within the `MachineBlockPlacement` pass (and you can probably make the same argument for various other passes as well that profiles work against consistency in code generation).
This is motivated by a scenario where binary size is regressed when PGO is used. Note that if we don't consume PGO data, we can still read from `MachineBranchProbabilityInfo` (and from `BranchProbabilityInfo`) because they are generated by analyzing the CFG. So if we ignore MBPI completely we would change the behavior even when PGO isn't used. I actually tried to add a flag to disable profile usage for this pass https://github.com/llvm/llvm-project/pull/102956, but we decided that https://github.com/llvm/llvm-project/pull/109711 was a better solution.
Basically, we still want to read profile data to improve the performance of critical functions, but we should avoid it for cold or `optsize` functions in some cases. I did something similar in https://github.com/llvm/llvm-project/pull/112960.
> Do we have any signal / flag to get an indication whether the user cares about ICF? I feel slightly uncomfortable in that this may regress users optimizing for size but not using any form of ICF / outlining...
In this case, flipping the branch does not impact code size because the number of instructions does not change. This optimization is purely for performance, which is not necessary for `optsize` functions. So this shouldn't regress size or performance. It could slightly improve compressed size or uncompressed size if outlining or ICF is enabled.
FWIW this edge case seems to be super rare. The code size win I saw was very small, but still noticeable.
https://github.com/llvm/llvm-project/pull/114607
More information about the llvm-commits
mailing list