Automatic PGO - Initial implementation (1/N)

Evan Cheng evan.cheng at
Wed Sep 25 17:54:06 PDT 2013

On Sep 25, 2013, at 9:29 AM, Diego Novillo <dnovillo at> wrote:

> 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
> phase.
>> 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
> fit.
> I'm open to better options, of course.

Hmm. Scalar transformation seems *wrong* but you are right it can't an analysis pass. A couple of ideas:

1. Can we implement it not as a pass but a utility that clients can use?
2. Move it to lib/Transform/Instrumentation?


> Diego.

More information about the llvm-commits mailing list