Automatic PGO - Initial implementation (1/N)

[Daniel Dunbar]

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 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.
>
>
> Diego.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130927/c88bae67/attachment.html>