<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/21/20 1:34 AM, Renato Golin via
llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAPH-gff+M391JN9t3KuvXR5YawwSEnmxNwtM8=xD6CG-EcU39g@mail.gmail.com">
<div dir="auto">+1 to Eric's point. We could get into a state
where we must get the relocation right in the IR to get a good
(or worse, any) lowering.
<div dir="auto"><br>
</div>
<div dir="auto">I'd rather have a canonical representation,
relocation friendly, that we try to keep and back ends know
how to lower well. </div>
<div dir="auto"><br>
</div>
<div dir="auto">--renato <br>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>FWIW, I think that we all agree to that. I don't see that what's
being proposed changes this general philosophy. The general
problem is: what happens when that lowering has multiple good
options, and the ABI requires particular choices under certain
circumstances?</p>
<p>Thanks again,</p>
<p>Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAPH-gff+M391JN9t3KuvXR5YawwSEnmxNwtM8=xD6CG-EcU39g@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 21 Aug 2020, 04:35
Eric Christopher via llvm-dev, <<a href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I do have concerns about the amount of object
level modeling that we want to do in the IR though. While it
isn't the highest level IR we've managed to mostly avoid
these kinds of features/complications in the past. I'm
definitely interested in hearing some alternate
implementations here and there rather than a full set of
constants for relocations. Keeping the IR abstract enough
over the object file level other than in generalizable cases
still feels like a win.
<div><br>
</div>
<div>-eric</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Aug 20, 2020 at
8:44 PM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>Hi Leonard,
<div><br>
</div>
<div>I haven’t looked at your patch in detail, but I
think that this is a step in the right direction. I
would like to see new “Constant*”’s that directly map
onto the relocations that various object formats use
(for example, macho has a relocation for
“&g1-&g2+cst”). This would get us to a more
principled lowering in many cases as well as make the
backend modeling more specific.</div>
<div><br>
</div>
<div>-Chris<br>
<div><br>
<blockquote type="cite">
<div>On Aug 20, 2020, at 11:29 AM, Leonard Chan
via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br>
<div>
<div dir="ltr"><span id="m_-2730480242623693538gmail-m_1235933234665458611gmail-docs-internal-guid-bcd6a4a8-7fff-6db4-f093-d40e55405145">
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Hi all,</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">We would like to propose a new Constant type in LLVM for representing entries in the Procedure Linkage Table (PLT).</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">The PLT is a data structure used for dispatching position-independent function calls to appropriate functions where the address of the function is not known statically. Right now, if a call is made to a function, it may be lowered to a direct call to the function itself or the PLT entry for that function. LLVM has checks that dictate if the function call should be a direct reference or PLT entry, but we don’t have a way in IR to semantically represent that the PLT entry should be used.</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">The proposed constant would be analogous to BlockAddress, but instead represent the PLT entry for functions. The usage could look something like:</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Inconsolata,monospace;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">pltentry(@function)</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">and would always have the same type as the function. A </span><span style="font-size:11pt;font-family:Inconsolata,monospace;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">pltentry</span><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> would operate exactly like a function, but the main difference is that it’s lowered to the PLT entry (</span><span style="font-size:11pt;font-family:Inconsolata,monospace;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">function@plt</span><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">) on targets that support PLT relocations. The linker can then decide if it should be relaxed into a direct reference or remain a PLT entry.</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">I have a very rough WIP implementation at </span><a href="https://reviews.llvm.org/D77248" style="text-decoration-line:none" target="_blank" rel="noreferrer" moz-do-not-send="true"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">https://reviews.llvm.org/D77248</span></a><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">.</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Thoughts and opinions?</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Thanks,</span></div>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Leonard</span></div>
</span><br>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" rel="noreferrer" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>