<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">James, thanks. Looking at that patch was enlightening. Indeed I think the intent was similar to the problem I’m trying to solve. In spite of that I’m not inclined
to use it since it had issues out of the box, is not an exact fit for my problem, and seems to be abandoned. I would not object to
<a name="_MailEndCompose">removing it.<o:p></o:p></a></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Alan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<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""> James Y Knight [mailto:jyknight@google.com]
<br>
<b>Sent:</b> Friday, November 22, 2019 1:22 PM<br>
<b>To:</b> Davis, Alan<br>
<b>Cc:</b> LLVM Developers Mailing List<br>
<b>Subject:</b> [EXTERNAL] Re: [llvm-dev] [MCAssembler] changing layout in assembler backend<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I don't really know the history, but I was just looking at this and wondering if I could rip out that entire infrastructure since it seems to be rather complex dead-code.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There's an abandoned follow-on patch <a href="https://reviews.llvm.org/D34396">https://reviews.llvm.org/D34396</a> that may be helpful to look at.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Nov 22, 2019 at 11:52 AM Davis, Alan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">… Replying to my own message since no one else did :-;
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">… and hoping for a little insight on the MCCodePadding class.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">Essentially I need a way to create alignment padding whose size can be adjusted based on the content (not just the address) of other MCFragments. (MCAlignFragments
don’t quite fit the bill because they only look at the next Fragment’s Offset, not its contents.) It seems like this sort of aligns with the purpose of MCCodePadder, which adjusts the size of an MCPaddingFragment based on other fragments. But MCCodePadder
is an enigma. No targets seem to use it; it has virtual methods as if it’s intended for targets to override it MCAssembler is hardwired to construct the base class; its addPolicy() is also protected from target access; and it’s not clear what it’s actually
intending to do – in particular I don’t get the “window” concept.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">Can anyone shed light on how this is supposed to work?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">-Alan
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_8070015094872264444__MailEndCompose"><span style="color:#1F497D"> </span></a><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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""> Davis, Alan
<br>
<b>Sent:</b> Wednesday, November 20, 2019 5:07 PM<br>
<b>To:</b> LLVM Developers Mailing List<br>
<b>Subject:</b> [MCAssembler] changing layout in assembler backend</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Our target has a perhaps unique problem relating to code alignment. Like other targets, it wants to insert NOPs for an FT_Align fragment. The unique part is that it has a way to
“fold” these NOPs into the previous instruction packet, so that when falling through to the aligned label there is no execution penalty. Doing so requires re-encoding the previous packet, which “enlarges” it such that no actual NOPs are needed.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So I’d like to do this in the target-specific MCAsmBackend, in the finishLayout hook which is called after the MCAssembler finishes the layout pass. The idea is to look for FT_Align
fragments, see how much padding they generate, find the previous packet, and re-encode it. The problem is that doing so changes the layout – sort of. Actually, it just changes the offset of the FT_Align fragment because the previous packet is larger. I could
just do that directly… but the Offset member is private to the Fragment and only settable by its friend the MCAsmLayout class.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I looked at doing this via relaxation but there is not enough context. In particular the backend’s relaxation API does not have access to the fragment list.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Also I noticed there is an interesting looking mechanism called MCCodePadder, but it’s super obtuse and no in-tree targets seem to use it.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">For now I just made MCFragment’s Offset public and modified it directly from finishLayout. But that seems like it significantly undermines the design. Ideally I think the MCAsmBackend
should have authority to do whatever it needs to do, including adjusting the layout (especially in an API called “finishLayout”) but currently that is not the case. I’m looking for advice on how to make this work with minimal changes to the existing APIs.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-Alan<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>