<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Sure, I also don’t like unnecessary complexity. Let me try to motivate this along two different points: expressivity, and simplicity.<div class=""><br class=""></div><div class="">On Expressivity, LLVM IR *in general* provides an abstract representation that allows frontends to generate target independent(ish!) IR, instead of having to understand all of the target details, e.g. you shouldn’t have to know the target to get an integer add. However, the model is really that we provide *both* a target independent model and a target-specific model. You can see this in calling conventions, you can see this in target-specific intrinsics, you can see this in inline assembly. In my opinion these are all good examples of LLVM providing target-independent abstractions, while still allowing frontends to get to the full capability of the hardware/architecture/target. Making addressing modes for relocations consistent with that seems like a good thing.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">On simplicity, I’ve mentioned before that the right thing is to redesign ConstantExpr entirely, eliminating most of the operations. “Trapping” constants (like divide) is a huge bug in the representation, and is only there for historical reasons. When you get beyond the fundamental integer and FP constants, the only reason we have aggregates (ConstantArray) and ConstantExpr is to enable global variable initializers that contain relocations. Things like constants (and particularly constant exprs) in PHI nodes are persistent problems at the LLVM IR level that would be better defined away. As such, a reasonable design for constants would be “fundamental constants within function bodies; possibly using an MLIR like representation to define away even these” and “global variable initializers”. Note that there is no specific reason that “global variable initializers” be Value*’s.</div><div class=""><br class=""></div><div class="">In any case, I think the first thing is motivation alone. Doing so would be a stepping stone to get rid of all the crazy backend logic that tries to match "gv-gv+cst” etc, instead allowing this to be done on the IR level.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 20, 2020, at 8:35 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""></div><div class="">-eric</div></div><br class=""><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" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class="">Hi Leonard,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-Chris<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 20, 2020, at 11:29 AM, Leonard Chan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><span id="gmail-m_1235933234665458611gmail-docs-internal-guid-bcd6a4a8-7fff-6db4-f093-d40e55405145" class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">Hi all,</span></div><br class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">We would like to propose a new Constant type in LLVM for representing entries in the Procedure Linkage Table (PLT).</span></div><br class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">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 class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">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 class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">pltentry(@function)</span></div><br class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">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" class="">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" class=""> 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" class="">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" class="">) 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 class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">I have a very rough WIP implementation at </span><a href="https://reviews.llvm.org/D77248" style="text-decoration-line:none" target="_blank" class=""><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" class="">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" class="">.</span></div><br class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">Thoughts and opinions?</span></div><br class=""><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">Thanks,</span></div><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><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" class="">Leonard</span></div></span><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>