<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/29/20 8:27 PM, Chris Lattner via
llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:0489E46F-1111-4134-8428-01859A4615D5@nondot.org">
On Aug 24, 2020, at 6:47 PM, Leonard Chan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>> wrote:
<div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">Thanks for the responses! I’m going
to see if I can summarize the concerns and ideas people
have (for my own clarity) and see where we can go on from
there. Folks seem to be on board with the idea of
introducing some new IR entity that (after linking)
*could* be a reference into the PLT, but some kinks need
to be worked out first:<br class="">
<br class="">
<b class="">Naming</b> (Thanks for clarifications
maskray@. I mixed up some terminology and concepts.):
Because the PLT is primarily the concern of the linker,
the naming probably shouldn’t be directly tied to “PLT”.
The initial proposal was for something that matched the
@plt modifier on x86, so that’s what inspired the naming.
The intended behavior of this IR level change is that at
least on x86 or aarch64, the resolved constant could be
lowered to something that has the `@plt` syntax, but I
suppose other targets could have their own meaning for
“the address of this function is insignificant.”<br class="">
<br class="">
<b class="">Abstraction</b>: The IR representation of this
probably shouldn’t be too strictly mapped to object file
representations. It’s useful to have an IR pattern that
can be mapped to relocations on different binary formats,
but we don’t want to introduce a state where we have new
Constants for individual relocations. The IR-entity should
remain abstract enough that it’s not tied to a specific
relocation, but it can still be lowered appropriately by
different backends.<br class="">
<br class="">
As an update to the proposal, instead of
`pltentry(@func)`, we can call it something like
`unnamedfunc(@func)` and everywhere it’s used, it means:
“The value used here is functionally equivalent to the
original function, but may not be a reference to the
original function. The address of this value is
insignificant.” This is leveraged from `unnamed_addr`
where the address of a global variable is insignificant,
but this would instead be tied to instances where the
function is used rather than be attached to the function
declaration/definition. `unnamedfunc(@func)` could be
lowered to a direct reference (func), the @plt modifier on
x86/aarch64 (func@plt), a thunk, or anything that’s
equivalent to the resolved function at runtime.<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
<div class="">Sorry for the delay responding Leonard. I don’t
really understand your rationale here. A PLT entry is a
completely target specific concept because some targets don’t
have PLTs. I don’t think there is any reason that a frontend
would abstractly generate this unless they already have a
target-specific plan in mind.</div>
<div class=""><br class="">
</div>
<div class="">If you go with your “unnamedfunc” approach, you’ll
have to define the semantics of what that means, and it will
need to mean something on targets without a PLT. If it isn’t
generally implementable, then it is target specific again.</div>
<div class=""><br class="">
</div>
<div class="">I feel like you are trying (earnestly!) to make the
IR better here, but by making this abstract it is actually just
making it more opaque for no obvious benefit.</div>
</blockquote>
<p><br>
</p>
<p>+1 to this. LLVM already has a large issue with implicit ABI
contracts between Clang (and other frontends) and the various
backends. We should not make that worse. The problem here is that
there are multiple ways to represent the reference to the function
symbol, and in this case, there's an ABI requirement to pick a
specific one of them. We should make that clear and explicit. If
there's an abstraction here that's useful, it's in the way to pass
along that target-specific information -- I think of this like a
target-specific attribute.<br>
</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:0489E46F-1111-4134-8428-01859A4615D5@nondot.org">
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">Implementation-wise, I imagine we
don’t want this as a subclass of GlobalValue. As Peter
suggested, this may not eventually lower to a symbol. If it
were a GlobalValue, that would also imply linkage types and
visibility would also apply to it which might not make
sense. A GlobalValue also seems to imply a module-level
entity when this would primarily be used on individual
locations where a function would normally be used.<br class="">
</div>
</blockquote>
</div>
<div class="">
<div dir="ltr" class=""><br class="">
</div>
</div>
<div dir="ltr" class="">I agree, this should be a subclass of
ConstantExpr.</div>
<div class=""><br class="">
</div>
<div class="">-Chris</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>