Automatic PGO - Initial implementation (1/N)

Daniel Dunbar daniel at
Fri Sep 27 11:22:21 PDT 2013

Hi Diego,

Off-topic from the patch, but can you say a bit more about this effective
this approach ended up being in GCC? Is there any kind of performance
analysis showing the wins from AutoFDO, or comparing its accuracy to
traditional FDO?

 - Daniel

On Wed, 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.
> Diego.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the llvm-commits mailing list