[PATCH] D119880: [FuncSpec] Support function specialization across multiple arguments.

Sjoerd Meijer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 15 01:49:14 PDT 2022


SjoerdMeijer added a comment.

In D119880#3380014 <https://reviews.llvm.org/D119880#3380014>, @labrinea wrote:

> That's true; the new formula is not in the current revision. The idea is to keep a sublinear number of specializations when the number of candidates grows enormously (not expected to happen in real life code). So imagine we had 1000 candidates n/2 would be 500 whereas `log10(n^4)+1` will be 13. I measured the instruction count of clang when compiling the llvm test suite with `log10(n^5)+1` ( this function has a steeper curve - see https://www.google.com/search?q=plot+log10(x%5E5)%2B1 ) and it had a significant impact on ClamAV (1% more instructions over baseline compared to 0,57% increase with `log10(x^4)+1`).

Oh okay, got it.

> Regarding your previous question; in order to use stable sort we would need to flatten the nested structure of `SmallDenseMap<Function *, SpecializationMap>` into a wider `SpecializationMap`, which would contain specializations of several functions in one data structure. The problem is that `calculateGains` currently expects an empty `SpecializationMap`, which corresponds to a single function, hence it would require heavy adaptation. I can experiment and see if it's worth pursuing this idea (maybe in follow up patches?).

Okay, cheers, will leave it up to you then. I expect both approaches to be very close in terms of compile times. Algorithmically it is the same I think. So it's more about readability of the code.

I am now going to read the whole patch again.



================
Comment at: llvm/lib/Transforms/IPO/FunctionSpecialization.cpp:134
 struct SpecializationInfo {
-  ArgInfo Arg;          // Stores the {formal,actual} argument pair.
-  InstructionCost Gain; // Profitability: Gain = Bonus - Cost.
-
-  SpecializationInfo(Argument *A, Constant *C, InstructionCost G)
-      : Arg(A, C), Gain(G){};
+  SmallVector<ArgInfo, 8> Args; // Stores the {formal,actual} argument pairs.
+  InstructionCost Gain = 0;     // Profitability: Gain = Bonus - Cost.
----------------
Nit: we might as well drop the 8 here. From the programmers manual:

> In the absence of a well-motivated choice for the number of inlined elements N, it is recommended to use SmallVector<T> (that is, omitting the N).


================
Comment at: llvm/lib/Transforms/IPO/FunctionSpecialization.cpp:339
+      if (!ForceFunctionSpecialization && MinGainThreshold == 0) {
+        // Sort the specializations based on Gain.
+        for (auto &Entry : Specializations) {
----------------
SjoerdMeijer wrote:
> This isn't clear to me, I don't see how we sort things. First, we add things to a map here....
If you keep this version, can you at least add that this is sorting the candidates using a map.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119880



More information about the llvm-commits mailing list