[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