[PATCH] D157123: [FuncSpec] Rework the discardment logic for unprofitable specializations.

[Chuanqi Xu via Phabricator via llvm-commits]

ChuanqiXu added inline comments.


================
Comment at: llvm/lib/Transforms/IPO/FunctionSpecialization.cpp:844-845
+      if (!ForceSpecialization &&
+         (VisitorBonus.CodeSize <= SpecCost / CodeSizeRatio ||
+          VisitorBonus.Latency / BonusRatio < VisitorBonus.CodeSize) &&
+          InliningBonus / BonusRatio < SpecCost)
----------------
I am wondering if the condition `||` may be too strict. My rough feeling is: it is good enough to perform specialization if we can see one of the benefits.


================
Comment at: llvm/lib/Transforms/IPO/FunctionSpecialization.cpp:902-903
-  //
-  // TODO: Perhaps we should consider checking such inlining opportunities
-  // while traversing the users of the specialization arguments ?
   Function *CalledFunction = dyn_cast<Function>(C->stripPointerCasts());
----------------
labrinea wrote:
> I couldn't think of an example where this would be useful, let alone that calling `getInlineCost` is expensive according to this comment:
> https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Analysis/InlineCost.h#L274
Maybe I just feel reusing the existing mature cost model may be a better choice. But given that is expensive and we're willing to build and fine-tunning our cost model. It may be good to not depend the expensieve  `getInlineCost`.


================
Comment at: llvm/lib/Transforms/IPO/FunctionSpecialization.cpp:919-921
   // The below heuristic is only concerned with exposing inlining
   // opportunities via indirect call promotion. If the argument is not a
   // (potentially casted) function pointer, give up.
----------------
Let's move the comment to the definition of the function. It will be much more clear.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D157123/new/

https://reviews.llvm.org/D157123