[PATCH] D36432: [IPSCCP] Add function specialization ability

[Matthew Simpson via Phabricator via llvm-commits]

mssimpso added a comment.

In https://reviews.llvm.org/D36432#839572, @dberlin wrote:

> In https://reviews.llvm.org/D36432#839506, @mssimpso wrote:
>
> > Danny/Davide,
> >
> > Thanks very much for the feedback. I have some replies to your comments below (abridged, so it's easier to read in Phab.), but I thought I would first summarize things so far. It sounds like your main points are that (1) the cost model for function specialization is difficult to get right in practice, and that (2) our current IPSCCP infrastructure could be improved to do better than pass-through for arguments and returns. I agree with both of these points. So do we think we should iterate on this patch and add function specialization to our current infrastructure?
>
>
> I'm not opposed if we have cases where it matters.
>  But if we can't find these cases, it's not gonna be turned on by default, and then i think our time would be better spent elsewhere.
>  IE i don't think it will be horribly useful to have function specialization but not have it good enough to be worth it by default.
>  At that point, i think'd we better off exploring different kinds of improvements (IE store function argument range info) to IPSCCP or different mechanisms of using the existing info (IE inlining)


I agree. Looking at the biggest performance winners from the current patch (spec2017/mcf, in particular), most of the improvement is coming from inlining (enabled after the indirect call promotion that specialization allows). I wonder if there's a better way to achieve this benefit without specializing. For example, we could propagate constant sets indicating the functions indirect call sites could possibly target. Although we would probably want to limit the size of the sets to something small, the pass could attach the sets via metadata to the calls so that this information could be consumed by later passes. Such metadata could be used for indirect call promotion, intersecting the function attributes of the possible targets (i.e., in CallSite::hasFnAttr), etc. We could perform this here in SCCP or in a separate pass using the generic solver. What do you think?


https://reviews.llvm.org/D36432