[PATCH] D93838: [LLVM] [SCCP] : Add Function Specialization pass

Chuanqi Xu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 15 20:34:53 PDT 2021


ChuanqiXu added a comment.

In D93838#2691276 <https://reviews.llvm.org/D93838#2691276>, @SjoerdMeijer wrote:

>> Thanks for sharing those sobering numbers. These seem to indicate that just adjusting the threshold may not be enough to control the excessive compile-time.
>
> Yes, that's a bit high, and not inline with additional compile-times we see with GCC. I haven't carefully looked into it yet, but those 10 number of iterations also look a bit arbitrary to me, and I am guessing we could do with less. But agreed that tuning this down may not solve this, so will look into this.

Noticed that there are many traversals in the code, I wonder if we can mitigate it by caching some results. I am not sure the hot spot in compilation time is in this code or in successive optimization.

In D93838#2691075 <https://reviews.llvm.org/D93838#2691075>, @fhahn wrote:

> Thanks for sharing those sobering numbers. These seem to indicate that just adjusting the threshold may not be enough to control the excessive compile-time.

Since the pass only run in LTO in LegacyPM, I wonder if the excessive compile-time is OK because LTO are time-consuming naturally. Although it looks like to be running as a module pass in NewPM, I don't know it's by design or just a miss.



================
Comment at: llvm/lib/Passes/PassBuilder.cpp:1126
+  if (EnableFunctionSpecialization != FuncSpecializationLevel::Disabled)
+    MPM.addPass(FunctionSpecializationPass());
+
----------------
The Function Specialization pass would only run in LTO mode in Legacy Pass manager while is seems like it would run as a module pass in NewPM. Is this a intended behavior?


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

https://reviews.llvm.org/D93838



More information about the llvm-commits mailing list