[PATCH] D34017: Do not early-inline recursive calls in sample profile loader.

[Xinliang David Li via llvm-commits]

On Wed, Jun 7, 2017 at 4:53 PM, Kyle Butt via Phabricator <
reviews at reviews.llvm.org> wrote:

> iteratee added a comment.
>
> In https://reviews.llvm.org/D34017#775713, @danielcdh wrote:
>
> > In https://reviews.llvm.org/D34017#775712, @iteratee wrote:
> >
> > > It doesn't have to blow it up exponentially. Can we clone the function
> to be inlined, re-writing the recursive calls to call the clone, and then
> inline that? Similar to a worker-wrapper transformation
> >
> >
> > You mean clone the caller before any inlining, and inline that copy
> instead of the caller itself in early inlining? Yes we could do that, but
> that adds unnecessary copy overhead for every caller (which could be
> large). As llvm does not do recursive inlining anyway, this only solves
> cases where profile is collected from gcc binary, which should be
> temporary. So I guess it's not worth the effort to special-handle recursive
> early inlining.
>
>
> I meant to do it only if the inline is recursive. The overhead should be
> much lower in that case.
> Clone the function, make the recursive calls call the clone, inline the
> clone. Repeat until you no longer want to inline any more, then take the
> remaining calls to the clone, and change them back. GC the clone. You could
> think of it as a kind of loop unrolling.
>

Note that early inlining for Sample PGO is mainly driven by the need of
profile matching. This patch  is not the right place to implement that.
What you described can be implemented in the main inliner pass which also
needs to deal with related inline cost (e.g, recursive inlining level etc)
-- recursive inlining is one of main missing features in LLVM inliner.

David




>
>
> https://reviews.llvm.org/D34017
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170607/55c2a80c/attachment.html>