<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=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:11.0pt;
font-family:"Calibri","sans-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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Arial","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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="color:#1F497D">We thought about putting the ‘this’ pointer into memory but that would mean that even small member functions would acquire a stack frame (on architectures where leaf routines can get away without one), which
may degrade performance considerably. You could apply some heuristics and determine when a store is unnecessary, but inlining may complicate things. A fake_use operation would be inlined like any other instruction.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">We performed some internal evaluations of location coverage (at –O1 on x86), and about half of the member functions already had 100% location coverage for the this pointer, mostly because they are small. For
these methods extending the live range to the end of the function would probably make no difference in code generation anyway. For the longer routines, a fake-use at the end of the function would probably cause a spill early on, similar to the effect of an
explicit store.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Another consideration is that we’d like to extend the concept to other variables as well. This ‘this’ pointer Is invariant, but other parameters and locals are generally not, so we believe extending the live
range would be a more general solution.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-- wolfgang<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></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""> Smith, Kevin B [mailto:kevin.b.smith@intel.com]
<br>
<b>Sent:</b> Monday, September 21, 2015 7:12 PM<br>
<b>To:</b> Pieb, Wolfgang<br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> RE: extending liveness of 'this' pointer via FAKE_USE opcode<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">Why extend the live-range?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">If it isn’t already in memory (and for many architectures, it is already in memory), put the this pointer into memory, and change the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">debug information so that the location-expression of the this parameter is marked to be that memory?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">That has two nice properties:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">1 – If you do this early (in the function IR, not necessarily in the pass ordering), it really only costs a single store, and doesn’t otherwise really affect
register allocation. Mark the memory itself in such a way that it cannot be deleted.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">2 – This is only required for architectures/calling conventions where the this ptr isn’t already in memory, and where this extra debugging is required/desired.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">Kevin Smith<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<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""> llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org">mailto:llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Pieb, Wolfgang via llvm-dev<br>
<b>Sent:</b> Monday, September 21, 2015 11:17 AM<br>
<b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> [llvm-dev] extending liveness of 'this' pointer via FAKE_USE opcode<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hello!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At Sony we've seen some serious customer interest in having the 'this' pointer visible throughout an entire function during<o:p></o:p></p>
<p class="MsoNormal">debugging. However, optimizations may eliminate it after its last use, so we've been looking for a way to artificially extend its
<o:p></o:p></p>
<p class="MsoNormal">liverange to the end of the function.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So far, the most compelling way we can think of, and one we have used successfully in the past in at least one other compiler,
<o:p></o:p></p>
<p class="MsoNormal">is to create a 'fake use' of the 'this' pointer at the end of the function, compelling the rest of the compiler to not optimize it away.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At the moment there doesn't seem to be a good way to create such a fake use in LLVM (please enlighten us if you know of one), so we are<o:p></o:p></p>
<p class="MsoNormal">proposing to introduce a new intrinsic (e.g. llvm.fake_use), which would take a single value argument, representing a use of that value.
<o:p></o:p></p>
<p class="MsoNormal">The intrinsic would be lowered to a new invariant TargetOpcode (e.g. FAKE_USE), which serves the same purpose at the MI level.
<o:p></o:p></p>
<p class="MsoNormal">Code emission would simply ignore the new opcode.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Frontends could use the intrinsic to extend liveranges of variables as desired. As a first use case, clang would accept a new option<o:p></o:p></p>
<p class="MsoNormal">(e.g. -fkeep-this-ptr) which would cause a fake use of 'this' to be inserted at the end of a function, making it available for inspection<o:p></o:p></p>
<p class="MsoNormal">throughout the entire function body.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One important note is that since such an option would affect code generation, it cannot be automatically enabled by -g. However, should there be
<o:p></o:p></p>
<p class="MsoNormal">eventually support for a -Og mode (optimize for debugging), that mode could enable it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Any comments or alternative ideas are appreciated.<o:p></o:p></p>
</div>
</div>
</body>
</html>