[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