[llvm-dev] AutoFDO sample profiles v. SelectInst,

[David Callahan via llvm-dev]

I agree, this a fundamental problem with how the AutoFDO maps addresses to statements.

I have an experimental build where, rather than turning off certain optimizations, I change the DebugLoc information when we hoist instructions into a new execution context. That avoids the problem of wrong branch weights but means some branch weights are inferred rather than measured.

Perhaps rather than limit optimizations we have a variant of '-g' which tolerates this kind of change


From: Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>>
Date: Wednesday, August 17, 2016 at 8:19 AM
To: Xinliang David Li <xinliangli at gmail.com<mailto:xinliangli at gmail.com>>
Cc: David Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>>, LLVM Dev Mailing list <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: Re: [llvm-dev] AutoFDO sample profiles v. SelectInst,


On Fri, Aug 12, 2016 at 12:15 PM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
+dehao.

There are two potential problems:

1) the branch gets eliminated in the binary that is being profiled, so there is no profile data

This seems like a fundamental problem for PGO. Maybe it is also responsible for this bug: https://llvm.org/bugs/show_bug.cgi?id=27359<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D27359&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=lFyiPUrFdOHdaobP7i4hoA&m=ySKs86N9LiBaTDmiRjbJJIGlO-z7BHXRaRnz-hS1Gno&s=ZkL9ORQxX1oNnyUFSaW9NT6PcpKuF8Ow5gqA-aEp7YA&e=> ?

Should we limit select optimizations in IR for a PGO-training build? Or should there be a 'select smasher' pass later in the pipeline that turns selects into branches for a PGO-training build? (I don't have a good understanding of PGO, so I'm just throwing out ideas...maybe a better question is: how do other compilers handle this?)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/4ab49a4a/attachment.html>