[llvm-dev] RFC: PGO Late instrumentation for LLVM

[Sean Silva via llvm-dev]

On Tue, Aug 11, 2015 at 11:07 AM, Diego Novillo via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> One aspect of this that I have not seen discussed is that middle-end
> instrumentation enables PGO optimizations to front-ends other than Clang.
>
> While I agree that FE instrumentation could be improved, it still requires
> every FE to implement essentially the same common functionality.  Having
> PGO instrumentation generated in the middle-end, allows us every FE to
> automatically take advantage of PGO.
>

This is a really good point, and I agree with it. We may have gotten off on
the wrong foot since Rong's email focused so heavily on comparing with the
frontend instrumentation. As far as I see it, Rong's proposal has a couple
different parts:

1. Infrastructure for IR-level instrumentation-based PGO
2. Changes to the pass pipeline so that a hypothetical IR-level
instrumentation-based PGO is more effective
3. MST algorithm with profile feedback for optimal placement of counter
updates.

I think 1. is a no-brainer, if only so that all LLVM clients can benefit
from PGO, and also (as you pointed out below) so that it can have an
exclusive focus on performance. If it is sufficiently flexible, it may even
make sense to restrict clang's frontend instrumentation-based profiling to
non-performance stuff, and have clang directly interoperate with the
IR-level PGO for performance-related PGO use cases, just like any other
frontend would.

Philip and Sanjoy, out of curiosity do you guys use your own
instrumentation placement for PGO? Is an IR-level PGO infrastructure
upstream something you guys would be interested in?

I think that 2. is something that once we have 1. we will be able to
evaluate better, but for now my opinion is that we should be able to make
good progress without digging into that.

I think that 3. is a no-brainer if it provides a really significant win,
but without 1. we can't really measure its effect in isolation. It also has
a usability problem since it requires feeding in an existing profile for
the *instrumented* build, but if the benefit is very significant this may
be worth it for some users. We will probably be able to easily refactor 1.
as needed into an MST approach that degrades gracefully to using static
heuristics in the absence of real profile information, so is not a
maintenance burden (maybe even helps by providing a good framework in which
to develop effective static heuristics).

For the time being, I think we can avoid discussion of 2. and 3. until we
have more of 1. working. So I think it would be most productive if we focus
this discussion on 1.


> Additionally, some of the overhead imposed by FE instrumentation is not
> really all that easy to get rid of.  You end up duplicating functionality
> that is more naturally implemented in the middle end.
>

Yeah, I was looking into a couple of other simple approaches and quickly
found out that I was basically replicating much of the sort of logic that
the inliner already has.

-- Sean Silva


>
> I see the two approaches as supplementary, rather than complementary.  One
> does not negate the other.  Some of the optimizations we'd do in the FE,
> may hurt coverage.  Instead, by instrumenting in the middle end, you can
> focus exclusively on performance (coverage be damned).
>
>
> Diego.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150811/8af84a9c/attachment.html>