[llvm] [FuncSpec] Improve accounting of specialization codesize growth (PR #113448)

Alexandros Lamprineas via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 25 07:47:39 PDT 2024


================
@@ -759,6 +771,14 @@ bool FunctionSpecializer::run() {
   SmallVector<Function *> Clones;
   for (unsigned I = 0; I < NSpecs; ++I) {
     Spec &S = AllSpecs[BestSpecs[I]];
+
+    // Check that creating this specialization doesn't exceed the maximum
+    // codesize growth.
+    unsigned FuncSize = getCostValue(FunctionMetrics[S.F].NumInsts);
+    if ((FunctionGrowth[S.F] + S.CodeSizeCost) / FuncSize > MaxCodeSizeGrowth)
+      continue;
----------------
labrinea wrote:

I think it is worth mentioning the background story. We initially came up with the FuncGrowth threshold to limit the overall codesize growth from being linear to the number of times the specializer runs. At first it NumIters was set to 1, and we increased it to 10 for enabling specialization of recursive functions. Imagine runnning 10 times yielded 10 times the original function size.

We have MaxClones to limit the amount of specializations per iteration. Within a single iteration of run, the growth has no effect basically unless you have many candidates (not the case for functions relying on promoteConstantStackValues). It is used to prevent the next iteration candidates. How can there be a N+1-th candidate if at the N-th step we decided to stop? (I am thinking of recursive functions).

Maybe we can keep `FunctionGrowth[S.F] += S.CodeSizeCost;` here but remove the early exit from the line above this comment. It should only remain in the isProfitable lambda in my opinion.

https://github.com/llvm/llvm-project/pull/113448


More information about the llvm-commits mailing list