[llvm] [CodeLayout] Size-aware machine block placement (PR #109711)
via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 1 14:16:09 PDT 2024
================
@@ -3545,15 +3559,19 @@ bool MachineBlockPlacement::runOnMachineFunction(MachineFunction &MF) {
}
}
- // Apply a post-processing optimizing block placement.
- if (MF.size() >= 3 && EnableExtTspBlockPlacement &&
- (ApplyExtTspWithoutProfile || MF.getFunction().hasProfileData()) &&
- MF.size() <= ExtTspBlockPlacementMaxBlocks) {
- // Find a new placement and modify the layout of the blocks in the function.
- applyExtTsp();
-
- // Re-create CFG chain so that we can optimizeBranches and alignBlocks.
- createCFGChainExtTsp();
+ // Apply a post-processing optimizing block placement:
+ // - find a new placement and modify the layout of the blocks in the function;
+ // - re-create CFG chains so that we can optimizeBranches and alignBlocks.
+ if (MF.size() >= 3) {
+ if (EnableExtTspBlockPlacement &&
+ (ApplyExtTspWithoutProfile || MF.getFunction().hasProfileData()) &&
+ MF.size() <= ExtTspBlockPlacementMaxBlocks) {
----------------
spupyrev wrote:
> It looks like this flag is used to avoid a large function that impacts the build time when running ExtTsp. Can it be a concern when applying for size?
I think the flag is pretty much obsolete for size, since there is no aggressive inlining in that case. The build time might be affected only when there are instances with ~10K+ of hot basic blocks. When that happens, we should probably investigate what's going on instead of silently ignoring optimizations.
I adjusted the code as you suggested.
https://github.com/llvm/llvm-project/pull/109711
More information about the llvm-commits
mailing list