<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" dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        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;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
p.Code, li.Code, div.Code
        {mso-style-name:Code;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:14.2pt;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        font-weight:bold;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB" style="text-align: left; direction: ltr; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div><br></div><div>On Wed, 2019-12-04 at 22:16 +0000, Simon Peyton Jones wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div class="WordSection1">
<p class="MsoNormal">Thanks Kavon.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What news of CpsCall in LLVM?  That seems crucial.</p></div></blockquote><div><br></div><div>CPSCall is in essence equivalent to an existing construct in LLVM for GC support called "statepoints." The difference is that CPSCall expects the front-end to allocate the stack frame, whereas statepoints are hooked into LLVM's stack-allocation infrastructure.</div><div><br></div><div>While our usage of CPSCall is correct by construction to not require LLVM's stack-allocation, LLVM's code generator has free-reign to generate stack spills across a CPSCall for values that one can trivially rematerialize. I don't think it's sustainable to work around that already deeply-ingrained behavior (however silly it may be!), so instead the plan is to extend LLVM's statepoints to be compatible with GHC's runtime system.</div><div><br></div><div>How we go about doing this depends on our desires: do we want to also use the native SP register or not? Some earlier investigation revealed that even on Windows, one could use a native SP that points to a heap-allocated object, provided ~512bytes of space is left beyond the SP for the kernel's interrupt handler. The implementation of Go does this, despite the Windows ABI forbidding it.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div class="WordSection1"><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I didn’t know of an effort to use a different SP register.  I seriously doubt that, with GHC’s use of zillions of small, heap-allocated stacks that move around during GHC, we’ll be able to leverage profiling or debugging tools in a serious
 way. But perhaps I need education.</p></div></blockquote><div><br></div><div>Existing debugging and profiling tools (e.g., gdb and Linux perf) can become more useful for GHC if they understood how to walk the call stack, regardless of whether the frame moves in memory. One way to do this is to emit call-frame information (CFI) [1,2] in the output assembly that describes the location and layout of the frame as it changes. This would work regardless of the SP register chosen and even if the return address is kept in register. An alternative to using CFI is to use a the canonical SP register and layout, since the default "CFI" assumed by these tools is the OS's ABI.</div><div><br></div><div>CFI is the most robust solution for GHC, since some functions allocate more than one frame per invocation to save on code size when applying a curried function (the Making a Fast Curry paper). This is of course orthogonal to the proc-point splitting concern.</div><div><br></div><div>I believe Ben originally brought up this desire to use a native SP even for the native backend, because the work of switching to gives us both automatic CFI support and some branch-predictor performance benefits on x86-64. That's likely to be a big overhaul though, so I'm personally in favor of extending LLVM's statepoints to be compatible with GHC and concurrently but separately adding CFI support for the native backend.</div><div><br></div><div><br></div><div>[1] <a href="https://sourceware.org/binutils/docs/as/CFI-directives.html">https://sourceware.org/binutils/docs/as/CFI-directives.html</a></div><div>[2] <a href="https://www.imperialviolet.org/2017/01/18/cfi.html">https://www.imperialviolet.org/2017/01/18/cfi.html</a></div><div><br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div class="WordSection1"><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Simon<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-devs <ghc-devs-bounces@haskell.org>
<b>On Behalf Of </b>Kavon Farvardin<br>
<b>Sent:</b> 04 December 2019 19:32<br>
<b>To:</b> Ben Gamari <ben@smart-cactus.org><br>
<b>Cc:</b> GHC developers <ghc-devs@haskell.org><br>
<b>Subject:</b> Re: new llvm IR callbr instruction useful for proc-point splitting?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hi Ben,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The Wiki now has a link to the Google Doc that Michal and I were working on to compile all of the notes into one place.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The key progress made on this front has been in evaluating the trade-offs of the design space being considered by GHC, but tested within Manticore.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm drafting a message today for the LLVM mailing list regarding one of our first options: defining a GHC ABI to redefine which stack-pointer register is used. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Once we have additional answers to the question "how much effort is it to add a GHC ABI to LLVM?", we can then then start a discussion on whether GHC wants to change instead by moving to a native stack-pointer register (to take advantage
 of existing debugging and profiling tools, etc).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ideally, we would then make a decision on which option to take and someone (perhaps a GSoC student with mentorship from myself and others) with spare time can work on it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Kavon<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On Wed, 2019-12-04 at 11:38 -0500, Ben Gamari wrote:<o:p></o:p></p>
</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<pre>Kavon Farvardin <<a href="mailto:kavon@farvard.in">kavon@farvard.in</a>> writes:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Yes, callbr is part of the discussion on removing proc-point splitting! <o:p></o:p></pre>
<pre>Soon there will be an announcement about a new working group dedicated to LLVM<o:p></o:p></pre>
<pre>issues such as this one on this mailing list. Anyone interested is welcome to<o:p></o:p></pre>
<pre>join our meetings.<o:p></o:p></pre>
<pre>We're currently gathering our notes together first, but you can have a look here<o:p></o:p></pre>
<pre>for a preview: <o:p></o:p></pre>
<pre><a href="https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/LLVM-Backend-Optimization">https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/LLVM-Backend-Optimization</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Hi Kavon,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>What ever happened to this? It came up during the GHC call and we<o:p></o:p></pre>
<pre>realized that none of us knew what the state of the proposal was. Is<o:p></o:p></pre>
<pre>this Wiki page still reflective of the current state of play?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Cheers,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- Ben<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
</blockquote>
</div>
</div>


</blockquote></body></html>