Automatic PGO - Initial implementation (1/N)

[Evan Cheng]

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

> 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.

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?

Evan

> 
> 
> Diego.