[PATCH] D21405: [PGO] IRPGO pre-cleanup pass changes

[Sean Silva via llvm-commits]

On Fri, Jul 29, 2016 at 9:19 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> chandlerc added a subscriber: chandlerc.
> chandlerc added a comment.
>
> In https://reviews.llvm.org/D21405#459364, @silvas wrote:
>
> > In https://reviews.llvm.org/D21405#459242, @mehdi_amini wrote:
> >
> > > I really don't like the fact that the PGO pipeline will be different
> from the non-PGO pipeline (other than what is required for
> instrumentations). I wonder what other people will think of that.
> >
> >
> > This was one of my initial concerns too:
> http://lists.llvm.org/pipermail/llvm-dev/2015-August/089058.html
> >  Jake and I (actually mostly Jake) did some basic measurements related
> to this and did not find any significant difference.
> >
> > Rong also did some measurements related to this in the initial RFC
> thread: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089425.html
> >
> > I agree though: generally speaking, we should avoid running too many
> passes before instrumentation precisely because they cause divergence
> between the PGO and non-PGO pipelines. Thankfully Jake and I found that on
> our games only pre-inlining was needed (running other optimizations before
> instrumentation did not help significantly for our test cases beyond the
> benefit of just pre-inlining).
>
>
> I'm glad this is just pre-inlining, I strongly agree that we should not
> diverge here.
>
> I actually continue to disagree with pre-inlining. I have said this
> repeatedly in the past, and I'm not sure where we reached consensus that
> pre-inlining was the right design, and where the discussion of the
> tradeoffs took place. The closest I could find was the thread you linked to
> Sean, but I don't actually see a lot of discussion of alternatives there,
> nor do I see much real discussion of the inliner at all outside of the fact
> that yes, it does work.
>

The original thread had some discussion of alternatives (and Rong even
tried took measurements comparing against the alternative I suggested).
Like David mentioned, the thread "RFC: Pass to prune redundant profiling
instrumentation" had additional discussion of some alternatives.

Also, there doesn't seem to be a way to get the context-sensitive benefit
without inlining of some sort prior to instrumentation. (except maybe
cloning/specialization to get context-sensitivity, but that could have a
large compile-time overhead and would affect inlining decisions later
anyway, so it is not clear that it is really an improvement).

-- Sean Silva


>
> I would be much more in favor of a design which instead of changing the
> pipeline to optimize differently (and thus having PGO vs. normal
> divergence) either:
>
> - Teaches the instrumentation pass to do the necessary (possibly
> interprocedural) analysis to instrument only in places it will be cheap, or
> - Teach the existing pipeline to actually optimize and transform the
> instrumentation code to remove the overhead as necessary.
>
> This way we have a single optimization pipeline that we turn profile info
> on and off of ,rather than twe pipelines.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D21405
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160730/f877d9a2/attachment.html>