<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Which leads me back to the previous suggestion: Leave the local-value handling in place, but generate those instructions without debug-locations; then after
the block is finished, attach the first non-null debug loc to the first local-value instruction. There should already be a pointer to either the last local-value instruction or the first non-local-value instruction, which should make finding the debug loc
to use reasonably cheap.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It's pedantically incorrect, but FastISel is generating those instructions out-of-order which is unexpected for –O0, and explicitly attaching the local-value
instructions to the first "real" statement should be a happier debugging experience.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eric Christopher [mailto:echristo@gmail.com]
<br>
<b>Sent:</b> Tuesday, May 19, 2015 2:38 PM<br>
<b>To:</b> Robinson, Paul; Sergey Dmitrouk; David Blaikie<br>
<b>Cc:</b> llvm-commits<br>
<b>Subject:</b> Re: Provide better -O0 assembly on request<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, May 19, 2015 at 2:34 PM Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">> -----Original Message-----<br>
> From: <a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvm-commits-" target="_blank">llvm-commits-</a><br>
> <a href="mailto:bounces@cs.uiuc.edu" target="_blank">bounces@cs.uiuc.edu</a>] On Behalf Of Sergey Dmitrouk<br>
> Sent: Monday, May 18, 2015 2:08 PM<br>
> To: David Blaikie<br>
> Cc: llvm-commits<br>
> Subject: Re: Provide better -O0 assembly on request<br>
><br>
> > Having a debug mode that changes the object code is a pretty hard line<br>
> we<br>
> > haven't crossed yet. There's been some mention of -Og which would<br>
> optimize<br>
> > for debuggability, which would be totally fine to affect codegen, but I<br>
> > don't know if this change would fit there either.<br>
><br>
> Yeah, -Og is somewhere between -O0 and other levels, not sure it should<br>
> be more debuggable than -O0.<br>
<br>
BTW agreeing with David. I did mean to say changing object code under -g*<br>
shouldn't happen in my previous reply but somehow didn't actually say it.<br>
<br>
My personal opinion about -Og is that it should basically be -O1 (that's<br>
what gcc does, in effect). But we don't want to regress -O0.<br>
<br>
><br>
> > It'd be best to try to find a solution that doesn't adversely affect<br>
> code<br>
> > generation. Paul's suggestion (or something that produces the equivalent<br>
> > behavior - essentially attribute the constant manifesting instructions<br>
> to<br>
> > whatever the first debug-located instruction is in the basic block) is<br>
> one<br>
> > option. Another would be to change the way these constants are emitted,<br>
> > sinking them down at least to their first use, and attributing them to<br>
> > that use. I haven't looked at the code enough to know how this would<br>
> > work/be implemented.<br>
><br>
> Solution that doesn't affect code generation a lot is fine with me, just<br>
> was<br>
> curious if anyone is interested in -O0 assembly with less optimizations.<br>
> Second option sounds like a better approach than block post-processing<br>
> to fixup initial location, for now I don't see why it won't work, but need<br>
> to actually try this. Thanks!<br>
<br>
Hmmmm sinking the instructions to the first use... I haven't looked at the<br>
bookkeeping in FastISel for a while so not sure whether this would add more.<br>
<br>
There's a vaguely related problem where sometimes it looks like FastISel<br>
pre-loads so many local values that it needs to *spill and reload* some due<br>
to register pressure. (It would be cheaper to rematerialize the value...)<br>
Maybe sinking values to the first use would help with that, although it<br>
would likely make register-in-use bookkeeping more complicated.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It's not particularly easy given the bottom up nature of fast-isel, at least not without impacting compile time even more.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">FWIW removing the local map is going to cause regressions in two places: compile time and execution time. While we don't "care" whether or not execution time at O0 is fast or not, we do care at least some and this would be pretty annoying.
The compile time impact is less clear, when we added the map it helped a bit, but I don't know how much it helps today.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm not sure there are any particularly good solutions given the tradeoffs here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-eric<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>