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

[Rong Xu via llvm-commits]

On Wed, Jun 15, 2016 at 2:52 PM, Sean Silva <chisophugis at gmail.com> wrote:

> silvas added inline comments.
>
> ================
> Comment at: lib/Transforms/IPO/PassManagerBuilder.cpp:245
> @@ -214,1 +244,3 @@
> +    addExtensionsToPM(EP_Peephole, MPM);
> +  }
>    if (!PGOInstrGen.empty()) {
> ----------------
> xur wrote:
> > mehdi_amini wrote:
> > > Where is this list coming from? How is it computed?
> > I came up this list. I'm open to add most passes.
> In testing our games, we did not observe a significant reduction in
> instrumentation overhead from adding passes after pre-inlining.
>
> For example, we started with the set of passes initially proposed in
> http://reviews.llvm.org/D15828. Then we removed individual passes until
> there was a significant change in performance of the instrumented build. We
> were able to remove all of them except for the inlining pass.
>
> I.e. only the inlining pass contributed significantly to reducing overhead
> of the instrumented build. I would be interested to see the results of this
> experiment on a subset of your benchmarks.
>
> I believe the reason for this is that in the codebases we were testing
> (PS4 games), there are a very large number of calls to trivial single-BB
> functions (e.g. Vec4::operator+). On one codebase I analyzed, over 80% of
> all counts in the profile are from single-BB functions.
>
>
> http://reviews.llvm.org/D21405
>
> I haven't formally measured the performance impact on the individual
passes. But I don't expect them to be big either. I remember I used
.483.xalancbmk once to test the performance. The impact for each individual
pass was not significant (comparing to the noise -- note spec has pretty
big noise level). But I did pick a few functions to see if each pass has
changed the IR. The answer was yes. Each pass, more of less, has changed
the IR.

-Rong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160615/df977b72/attachment.html>