Automatic PGO - Initial implementation (1/N)

[Diego Novillo]

On Wed, Sep 25, 2013 at 12:11 PM, Evan Cheng <evan.cheng at apple.com> 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 (http://gcc.gnu.org/wiki/AutoFDO). 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.