Automatic PGO - Initial implementation (1/N)
echristo at gmail.com
Fri Sep 27 11:28:20 PDT 2013
Here's Dehao's talk at the GNU Tools Cauldron:
On Fri, Sep 27, 2013 at 11:22 AM, Daniel Dunbar <daniel at zuster.org> wrote:
> 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
>> > 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
>> I'm open to better options, of course.
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits