<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 15 (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;}
/* 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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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 faced a similar issue in LLILC, where our runtime requires us to report certain GC pointers as live (and have their values preserved) throughout certain methods. We considered some sort of fake_use construct,
but we need these things to be live even in code that doesn't reach return (e.g. paths that end in a noreturn call and `unreachable`), and weren't keen on adding them to all such paths (and making sure optimizations can't expose new such paths as they discover
that code is unreachable), nor did we put much thought into how that might interfere with tailcall generation/modeling. So, at least for now, we're calling the @llvm.localescape intrinsic on these addresses in the function entry block, with the expectation
that doing so will make them appear live wherever we need them to be (which specifically is GC safe-points, which for us all involve calls to external code).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Your situation sounds different both in that you want this for debugging whereas we need it for correctness (so maybe the paths that lead to unreachable or infinite loops aren't as interesting for you) and in
that you may care about extending liveness past the last call (unlike we who just need to cover the GC safe-points), but FYI that's what we've done in a somewhat similar situation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">We'd be happy to have something to use that's explicitly for lifetime extension, so long as it covers the paths which don't reach return.<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">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Joseph<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org]
<b>On Behalf Of </b>Pieb, Wolfgang via llvm-dev<br>
<b>Sent:</b> Monday, September 21, 2015 2:17 PM<br>
<b>To:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> [llvm-dev] extending liveness of 'this' pointer via FAKE_USE opcode<o:p></o:p></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>
</body>
</html>