<html 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 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:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* 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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.gmaildefault
{mso-style-name:gmail_default;}
span.EmailStyle23
{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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Thanks for pointer to <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D73739&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=HlATw2CSJtDwZKMxZp741A&m=fw0QGLuBqIldiyAqSFQHTqUf-RDXmlvm6SYWv4mUcNw&s=VlUYBt2UBSgb_lYyLthx8VN8GoakTTtAc9wJhUIqwMs&e=" target="_blank">
https://reviews.llvm.org/D73739</a>. Large part of that patch of involves coping with the dis-contiguity resulted from BB section, so EH table need to be broken up. If we want EH pad splitting to work with regular function (without BB section), it looks to
me that the flexibility from explicit LPStart, plus the change to deal with zero offset landing pad should be enough?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We’re looking into separating out EH pads too as Modi pointed out, even without profile data. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Wenlei<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Modi Mo via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Reply-To: </b>Modi Mo <modimo@fb.com><br>
<b>Date: </b>Monday, August 10, 2020 at 6:09 PM<br>
<b>To: </b>Snehasish Kumar <snehasishk@google.com>, Rahman Lavaee <rahmanl@google.com><br>
<b>Cc: </b>aditya kumar <hiraditya@gmail.com>, llvm-dev <llvm-dev@lists.llvm.org>, David Li <davidxl@google.com>, "efriedma@codeaurora.org" <efriedma@codeaurora.org><br>
<b>Subject: </b>Re: [llvm-dev] [RFC] Machine Function Splitter - Split out cold blocks from machine functions using profile data<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">On 8/10/20, 4:51 PM, "Snehasish Kumar" <<a href="mailto:snehasishk@google.com">snehasishk@google.com</a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><a href="mailto:rahmanl@google.com" target="_blank">+Rahman Lavaee</a> who is working on exception support for basicblock sections. </span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Aug 10, 2020 at 4:29 PM Modi Mo <<a href="mailto:modimo@fb.com" target="_blank">modimo@fb.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify"><span style="font-family:"Arial",sans-serif;color:black">>Exceptions</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify"><span style="font-family:"Arial",sans-serif;color:black">>All eh pads are grouped together regardless of their coldness and are part of the original function. There are outstanding issues with splitting
eh pads if they reside in separate sections in the binary. This remains as part of future work.</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify"><span style="font-family:"Arial",sans-serif;color:black"> </span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify">Can you elaborate more on the outstanding issues with splitting eh pads?<o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify"> <o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify">From my dip into the unwind map in gcc_except_table the current encoding to landing pads using function-start relative offsets doesn’t extend well to moving the pads somewhere else. Are there additional
issues with splitting specific pads out?<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span class="gmaildefault"><span style="font-size:12.0pt">That's correct, we have a pending patch to add support for this. </span></span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D73739&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=HlATw2CSJtDwZKMxZp741A&m=fw0QGLuBqIldiyAqSFQHTqUf-RDXmlvm6SYWv4mUcNw&s=VlUYBt2UBSgb_lYyLthx8VN8GoakTTtAc9wJhUIqwMs&e=" target="_blank">https://reviews.llvm.org/D73739</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="gmaildefault">IIUC with this patch, we can treat a set of ehpads as hot or cold and move them around as needed.</span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify"> <o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify">Best,<o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt;text-align:justify">Modi<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoPlainText">Thanks for the link!<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Looks like the flexibility to define landing pad start (LPStart) is already built into the EH metadata format. Taking advantage of that should allow ehpads to go anywhere they please.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">I’m looking at the runtime support and while gxx_personality_v0 (The C++ handler) does read LPStart gcc_personality_v0 (The C handler) purposefully
<b>ignores</b> it. Pads in C can be generated due to “__attribute__((cleanup(func)))”. If C code is a candidate for these transforms this probably needs to be fixed up.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</body>
</html>