Automatic PGO - Initial implementation (1/N)

Diego Novillo dnovillo at
Wed Sep 25 09:29:44 PDT 2013

On Wed, Sep 25, 2013 at 12:11 PM, Evan Cheng <evan.cheng at> wrote:
> Hi Diego,
> I am curious. Why is this called automatic PGO? Why is it automatic?

The name is derived from the first implementation that we implemented
at Google ( It's "automatic" because
it does not rely on instrumentation. The goal is to use external
sources of profile (the most common example is Perf or Oprofile),
which provide low overhead and can be applied to production
deployments. So, we can also get rid of the traditional training

> Also, why is the auto-profile part done as a scalar transformation pass? Did you consider alternatives?

This may be just me not knowing where to do this properly. Initially,
I had implemented it as an analysis, but since it modifies the code I
was violating the principle that analyses are not supposed to modify
the IR. The transformation does not need interprocedural information,
so putting it in the scalar transformations module seemed like a good

I'm open to better options, of course.


More information about the llvm-commits mailing list