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

[Chuanqi Xu via Phabricator via llvm-commits]

ChuanqiXu added a comment.

In D93838#2770233 <https://reviews.llvm.org/D93838#2770233>, @davidxl wrote:

> In D93838#2770226 <https://reviews.llvm.org/D93838#2770226>, @ChuanqiXu wrote:
>
>> In D93838#2770225 <https://reviews.llvm.org/D93838#2770225>, @davidxl wrote:
>>
>>> If the function pointer points to a function too large to be inlined,  I expect the benefit of cloning the caller will also be minimal.
>>
>> It depends on the number of callsites. But for the example in mcf, I agree with you that cloning may be not more beneficial than inlining.
>>
>>> What I am saying is that for the motivating example in MCF, it may be possible to fix the inliner.
>>
>> I agree with that if is possible to inline spec_qsort by adjusting the bonus. And what I am saying is function specialization is valuable and important.
>
> If it is valuable and important, definitely go for it :)
>
> My question is other than MCF, do we have other real world app that can benefit from this optimization (that can not be done by inliner)?  I saw omnetpp also improves, do you know where it helps ?  Also with PGO, do we see similar improvement?
>
> Asking these because there are compile time and code size consequences..



> I saw omnetpp also improves, do you know where it helps ?

We get omnetpp with 10~20 iterations in the past. And now the default iteration limit is 1. I didn't look into it. I would try if possible.

> Also with PGO, do we see similar improvement?

Good question, we need to experiment to answer it.

> Asking these because there are compile time and code size consequences

When we limit the iteration to one, as the data provided by @SjoerdMeijer

> My question is other than MCF, do we have other real world app that can benefit from this optimization (that can not be done by inliner)?

For this question, my answer is that the **current** implementation may affect real word applications little from the cost model I had visited. My thought is that it should be a long term process to tune the cost model. It is hard to image that we can make something good enough at one commit.

---

BTW, from the discussion, we are in consensus that cloning are beneficial to handle the cases that inlining can't. But in the current pass pipeline, function specialization is in the front of inlining pass. I am not sure if it is harmful. But I wonder if it is good to put inlining pass in the front of function specialization pass,. And if function specialization pass made changes, we could run inlined again.


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

https://reviews.llvm.org/D93838