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

[Robinson, Paul via llvm-dev]

If AutoFDO is using debug info to map instructions back to source locations, then the problem is that debug info (at least DWARF) cannot describe the situation where one instruction in effect comes from two different places.  This is a long-standing problem for debugging optimized code, and I guess would affect AutoFDO as well.  We can either assign the instruction to one of the source locations (which is a lie part of the time) or we can say we don't know where it comes from (which is kind of always true as the origin is ambiguous).  I know that the debugging experience is not great the way things are now, but I don't know whether it would be better if we started saying we don't know where the code comes from.

There are a variety of optimizations that would have to address this: branch folding, various combines, tail merging, probably more.  Right now I think they all just pick one somewhat arbitrarily.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Callahan via llvm-dev
Sent: Wednesday, August 17, 2016 9:07 AM
To: Sanjay Patel; Xinliang David Li
Cc: LLVM Dev Mailing list
Subject: Re: [llvm-dev] AutoFDO sample profiles v. SelectInst,

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/1c966c36/attachment.html>