[PATCH] D83743: [InlineAdvisor] New inliner advisor to replay inlining from optimization remarks

[Wei Mi via llvm-commits]

On Wed, Jul 15, 2020 at 10:03 PM Wenlei He via Phabricator <
reviews at reviews.llvm.org> wrote:

> wenlei added a comment.
>
> In D83743#2153532 <https://reviews.llvm.org/D83743#2153532>, @wmi wrote:
>
> > Thanks for the explanation.
> >
> > > We could also replay CGSCC inline of one build in another. The way
> it's implemented would work for those scenarios.
> >
> > When you replay CGSCC, the inline decision in replay file should have
> order? If it is unordered, I cannot see how it can replay CGSCC inline from
> another build exactly.
>
>
> I might be missing something, but here's how I think about this. For a
> given inline decision, say D on A->B->C path, we would only evaluate once
> and make that decision once. Then for replay, assuming we follow the same
> bottom-up order


Ok, that is the assumption I didn't hold before. That means the source and
compiler shouldn't be changed between the last build and the replay.



> , for each call site, we can retrieve that exact decision from input
> remarks, and as long as we make the same decisions, the sequence of call
> sites that gets exposed for evaluation will also be the same. Because we
> evaluate call site for each path only once,


That may not be true for CGSCC inline because one SCC can be visited
multiple times after the indirect call promotion or inline cleanup
add/remove the SCC edges.



> any decision recorded in remarks should be unique, then I'm not sure how
> order of the inline remarks interfere with replay.
>
> >
> >
> >> Our current use case is not in the SCC inliner. But yeah, I image it
> could be useful there too. In general I feel some mechanism like this one
> to allow external input for tweaking inlining decision can be useful,
> mostly for tuning and experimental purpose. We currently don't have a good
> way of doing that, existing attributes like alwaysinline is function level,
> not call site level. And per-callsite inline intrinsic like
> https://reviews.llvm.org/D51200 is intrusive and hard to push through
> either. I thought this is a relatively easy and clean way of getting that
> functionality for tuning.
> >
> > That is the scenario I am interested -- using it for tweaking inlining
> decision for tuning/experimental purpose. I understand it could need a lot
> more work than this patch and we may not need to address them currently. I
> just want to know how it should work in your mind. Could you explain it in
> more detail?
>
> I am considering different modes for replay in the future, the first is
> strict mode like what we have here - we simply replay everything
> faithfully. The second mode is positive replay, e.g. we only apply extra
> inlining using the input. A third mode can be negative replay, that is we
> prohibit inlining specified in input without affecting others.
> Orthogonally, we sometime may also want to focus on a specific inline tree,
> so it may be useful to have an unknown decision from advisor, then we can
> fall back to other advisors for decisions outside of the inline tree
> specified in input.
>

Ok, thanks.



>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D83743/new/
>
> https://reviews.llvm.org/D83743
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200715/1013e30d/attachment.html>