<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/1/21 5:48 PM, Philip Reames wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bd24ce25-37bd-08f7-3fd5-f7d50736d24f@philipreames.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>The basic problem you're solving makes sense to me, and I agree
we need a good solution. I'm not quite sure that your propose
is the right starting point though.<br>
</p>
<p>The notion of having different ways to encode targets with
different offsets shows up in a bunch of different ways, not
just calls, and in particular, not just the pcRel32 flavor you
mention here. A few other examples:</p>
<ul>
<li>For an address which whose relative offset is unknown, but
whose absolute address is known, you can use a 32bit move to
materialize the address in a register.</li>
<li>For relative calls, x86 supports a 16 bit relative version
as well. Though, I'm not sure this is profitable on modern
hardware.</li>
<li>With tail calls, you get all the jump variants (8b relative,
16b relative, 32b relative, 32b register, 64b register). <br>
</li>
<li>For data accesses, we have many of the same options. I
think it's reasonable to (mostly) start with calls, and ignore
the data access side of things. </li>
</ul>
<p>All of these tightly interlock with the relocations available
from the dynamic loader.</p>
<p>I'd previously played with specifying bounds on the absolute
addresses of functions. (We have some bit of support for that,
though I can't find it in LangRef currently.) This quickly
tripped into implementation complexity problems, but I didn't
see any fundamental reason why e.g. having both callee and
caller functions specified to be within a 1.x GB region wouldn't
allow us to use 32 bit relative calls. <br>
</p>
</blockquote>
<p>The syntax I couldn't find was <a moz-do-not-send="true"
href="https://llvm.org/docs/LangRef.html#absolute-symbol-metadata">absolute_symbol</a>.
There does appear to be some precedent using that mechanism, but I
don't see that it's been applied to calls.</p>
<p>I vaguely remember I stopped working on this when a rough
prototype failed to show profitability. <br>
</p>
<blockquote type="cite"
cite="mid:bd24ce25-37bd-08f7-3fd5-f7d50736d24f@philipreames.com">
<p> </p>
<p>I think we need to phrase this as a set of restrictions on both
the absolute and relative offset of a callee, and then leave it
up to backend to select the optimal lowering. The codemodel in
this world becomes simply the default set of restrictions for an
otherwise unspecified target address. <br>
</p>
<p>All of the above is a really involved way of saving that I
think you need to change your spelling on the attribute a bit.
I think we need to be able to support fairly arbitrary
restrictions on the relative range, and then leave it up to the
code generator which option it actually picks. As a strawman,
how about the following syntax:</p>
<p>call void @foo() target-address-relative-bound(-2147483648,
2147483647)</p>
<p>OR</p>
<p>declare void @foo() address-absolute-bound(X, X + 100MB)</p>
<p>Philip</p>
<p>p.s. I'm not a linker or loader person, I know just enough
about them to be very dangerous. If anyone who is actually
familiar with relocation types wants to tell me something is
horrible wrong with my proposed model, please feel free. :)<br>
</p>
<div class="moz-cite-prefix">On 9/1/21 6:31 AM, Evgueni Brevnov
via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHosswh9dzur5WPaDnCaxsTHRwbyJsDDmPB3obzWuDdzREiVUg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">Hi Everyone,
<div><br>
</div>
<div>Introduction:</div>
<div>On Intel x86_64 architecture you can make a call using
either relative 32 bits offset or absolute address.
Currently LLVM uses a notion of "code model" that defines
which version will be generated. In other words, for small
and medium code models 32 bits relative calls are generated,
for large code model calls via an absolute address are
generated. The thing is that a single lowering scheme is
used for the entire compilation unit and there is no way to
specialize for a particular call. In managed environments
(JIT compilers) we have control where specific functions are
loaded in memory and can guarantee that particular call site
is within 32-bits offset. We would like to use relative
calls for such functions while the global code model is set
to 'large'.</div>
<div><br>
</div>
<div>Proposal:</div>
<div>Introduce 'fits-32bits' call site attribute. For calls
marked with the attribute compiler may assume the target
address is within 32-bits offset from the end of the
generated call. Program semantics is not changed if it is
ignored by the compiler.The attribute overrides the current
code model for the specific call site.</div>
<div><br>
</div>
<div>Thanks</div>
<div>Evgeniy</div>
<div><br>
</div>
<div>
<div><br>
</div>
<div><br>
</div>
</div>
</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" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>