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

Sjoerd Meijer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 2 03:56:33 PDT 2021


SjoerdMeijer added a comment.

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

> In D93838#2784592 <https://reviews.llvm.org/D93838#2784592>, @SjoerdMeijer wrote:
>
>> Ran clang-format.
>>
>> @fhahn:  about running the solver first before making IR changes. I think that is happening already. There are some places where the solver is kept up to date after transformations. I think this is a remainder of running function specialisation iteratively that I stripped out for now, but I think it's good to keep these updates to the solver as it's probably good to keep it consistent.
>
> I'm not sure I'm looking at the right thing, but it looks like the specialization is still run iteratively via the code below? `RunSCCPSolver` seems to modify the IR after solving. Maybe I am looking at the wrong thing?
>
>   while (FuncSpecializationMaxIters != I++ &&
>          FS.specializeFunctions(FuncDecls, CurrentSpecializations)) {
>   
>     // Run solver for the specialized functions only.
>     RunSCCPSolver(CurrentSpecializations);
>   
>     CurrentSpecializations.clear();
>     Changed = true;
>   }

Ah okay, you're right, the solver runs but only for the specialised functions like to comments says. The main solving happens earlier in `runFunctionSpecialization`. Like I also wrote earlier, I have been stripping out a few things from the initial version, like running 10 iterations and doing it recursively, to prepare a basic version for an initial commit and get a baseline for the extra compile time costs.  I will get rid of invoking the solver here and add a TODO and will also get rid of the disabled test for now. From memory, I think that needed to run more iterations to kick in, but will look at that later in a follow up.

> Do we have test cases where the specialization leads to the function result of the specialized function becoming another constant, enabling further simplification in the caller?

Yeah, I think test `test/Transforms/FunctionSpecialization/function-specialization.ll` is an example of that: the specialised functions completely disappear because of further simplifications.


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

https://reviews.llvm.org/D93838



More information about the llvm-commits mailing list