Sanjay Patel via llvm-dev
2016-Aug-17 15:19 UTC
[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> 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 ? 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/c6276df2/attachment.html>
David Callahan via llvm-dev
2016-Aug-17 16:06 UTC
[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/4ab49a4a/attachment.html>
Xinliang David Li via llvm-dev
2016-Aug-17 16:12 UTC
[llvm-dev] AutoFDO sample profiles v. SelectInst,
On Wed, Aug 17, 2016 at 8:19 AM, Sanjay Patel <spatel at rotateright.com> wrote:> > On Fri, Aug 12, 2016 at 12:15 PM, Xinliang David Li via llvm-dev < > 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 ? > > 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?) > >For instrumentation based PGO (IR-based), this is a known problem. I have a solution for it and will send out patches soon. Before that, there will be more changes in LLVM to make sure profile data associated with selectInst is well preserved. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/e9912bcd/attachment.html>
Xinliang David Li via llvm-dev
2016-Aug-17 16:13 UTC
[llvm-dev] AutoFDO sample profiles v. SelectInst,
The problem reported by David here is for Sample FDO/PGO, not instrumentation based PGO. David On Wed, Aug 17, 2016 at 9:12 AM, Xinliang David Li <xinliangli at gmail.com> wrote:> > > On Wed, Aug 17, 2016 at 8:19 AM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> >> On Fri, Aug 12, 2016 at 12:15 PM, Xinliang David Li via llvm-dev < >> 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 ? >> >> 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?) >> >> > For instrumentation based PGO (IR-based), this is a known problem. I have > a solution for it and will send out patches soon. Before that, there will > be more changes in LLVM to make sure profile data associated with > selectInst is well preserved. > > Thanks, > > David > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/f12f4595/attachment.html>
Sanjay Patel via llvm-dev
2016-Aug-17 17:06 UTC
[llvm-dev] AutoFDO sample profiles v. SelectInst,
On Wed, Aug 17, 2016 at 10:12 AM, Xinliang David Li <xinliangli at gmail.com> wrote:> > > On Wed, Aug 17, 2016 at 8:19 AM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> >> On Fri, Aug 12, 2016 at 12:15 PM, Xinliang David Li via llvm-dev < >> 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 ? >> >> 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?) >> >> > For instrumentation based PGO (IR-based), this is a known problem. I have > a solution for it and will send out patches soon. Before that, there will > be more changes in LLVM to make sure profile data associated with > selectInst is well preserved. >Sounds great. Let me know if I can help without getting in your way. If there's more like https://reviews.llvm.org/D23590 , I can try to fix them up in parallel. On a related note, I want to ask about profile-guided inlining. It does not seem to exist after https://reviews.llvm.org/D16381 was reverted. Is there a plan to bring it back independently of the new pass manager? Profile-guided inlining was the original motivation for the test case in https://llvm.org/bugs/show_bug.cgi?id=28964 . But I think we'll miss this case if we fix SimplifyCFG to produce a 'select' before fixing IR-based PGO (and making inlining work again)? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/40d29e17/attachment-0001.html>
Robinson, Paul via llvm-dev
2016-Aug-17 19:00 UTC
[llvm-dev] AutoFDO sample profiles v. SelectInst,
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>