<div dir="ltr">That would be ideal, but the code generator needs to know the relative distance from the call site to the called function: which is only known at link-time.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 30, 2016 at 9:46 AM Russell Wallace <<a href="mailto:russell.wallace@gmail.com">russell.wallace@gmail.com</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">Can't the code generator do this opportunistically? That is, generate the more compact instruction sequence if the address happens to be within four gigabytes, otherwise generate the longer form?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 30, 2016 at 1:53 PM, Matt Godbolt <span dir="ltr"><<a href="mailto:matt@godbolt.org" target="_blank">matt@godbolt.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">For what it's worth we did a similar thing, but overrode RTDyldMemoryManager directly This allowed us to control where the RAM was allocated too (e.g. guarantee it was in the low 4GB so we could use small memory model and avoid the mov rax, xxxxxxx; call rax code generated for x86)*, and also override findSymbol() to have the same behaviour as described in 4).<div><br></div><div>--matt<br><div><br></div><div>* later issues in not always being able to allocate low ram caused us to drop this feature. I wish we could fix the "call rax"es :)</div><div><div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 29, 2016 at 6:51 PM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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 text="#000000" bgcolor="#FFFFFF">
There is no documentation I know of. Rough sketch:<br>
1) Create a subclass of SectionMemoryManager<br>
2) Create an instance of this class and add it the EngineBuilder via
setMCJITMemoryManager<br>
(Make sure everything runs without changes)<br>
3) Override the getSymbolAddress method, have your implementation
call the base classes impl<br>
(Make sure everything runs without changes)<br>
4) Add handling to map name->address for any custom functions you
want.</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<br>
<div>On 03/28/2016 09:18 PM, Russell Wallace
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">True, I care more about how fast the code runs than
how long it takes to compile it. So if the symbolic approach
enables better code generation, that is a very significant
advantage from my perspective.
<div><br>
</div>
<div>Is there any example code or documentation you can point to
for details about how to implement the symbolic approach? Is
it similar to any of the versions of Kaleidoscope or any other
extant tutorial?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 29, 2016 at 5:07 AM, Philip
Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Other advantages of keeping things symbolic:<br>
1) You can use function attributes to provide
optimization or semantic information.<br>
2) Linking modules works as expected when one of them
contains the definition.<br>
3) You can get better code generation (i.e. pc relative
addressing for local symbols, etc..)<br>
<br>
If the inttoptr scheme makes you happy, go for it. I'm
not telling you its wrong, merely that there's another
approach you should consider which has it's own
advantages. <br>
<span><font color="#888888"> <br>
Philip<br>
</font></span><br>
p.s. Your point about compiling faster is off base. Not
because you're wrong, but because if you're trying to
optimize for compile speed at that granularity, you
really don't want to be using LLVM (or just about any
framework.) LLVM does not make a good first tier JIT.
It's makes a great high tier JIT, but if you really
really care about compile time, it is not the
appropriate answer. <br>
<div>
<div> <br>
On 03/28/2016 08:57 PM, Russell Wallace wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">Ah! Okay then, so you are saying
something substantive that I think I disagree
with, but that could be because there are relevant
issues I don't understand.
<div><br>
</div>
<div>My reasoning is, I've already got a pointer
to the function I want the generated code to
call, so I just supply that pointer, it looks
ugly on a microscopic scale because there are a
couple of lines of casts to shepherd it through
the type system, but on an even slightly larger
scale it's as simple and elegant as it gets: I
supply a 64-bit machine word that gets compiled
into the object code, there are no extra layers
of machinery to go wrong, no nonlocal effects to
understand, no having to wonder about whether
anything depends on symbol information that
might vary between debug and release builds or
between the vendor compiler and clang or between
Windows and Linux; if it works once, it will
work the same way every time. As a bonus, it
will compile slightly faster.</div>
<div><br>
</div>
<div>Keeping things symbolic - you're saying the
advantage is the intermediate code is easier to
debug because a dump will say 'call print'
instead of 'call function at 123456'? I can see
that being a real advantage but as of right now
it doesn't jump out at me as necessarily
outweighing the advantages of the direct pointer
method.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 29, 2016 at
4:37 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank"></a><a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>I think our use cases are actually
quite similar. Part of generating the in
memory executable code is resolving all
the symbolic symbols and relocations. The
details of this are mostly hidden from you
by the MCJIT interface, but it's this step
I was referring to as "link time". </div>
<div><br>
</div>
<div>The way to think of MCJIT: generate
object file, incrementally link, run
dynamic loader, but do it all in memory
without round tripping through disk or
explicit files. </div>
<span><font color="#888888">
<div><br>
</div>
<div>Philip<br>
<br>
<br>
</div>
</font></span>
<div>
<div>
<div><br>
On Mar 28, 2016, at 7:25 PM, Russell
Wallace <<a href="mailto:russell.wallace@gmail.com" target="_blank">russell.wallace@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Right, but when you
say link time, the JIT compiler
I'm writing works the way openJDK
or v8 do, it reads a script, JIT
compiles it into memory and runs
the code in memory without ever
writing anything to disk (an
option for ahead of time
compilation may come later, but
that will be a while down the
road), so we might be doing
different things?</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue,
Mar 29, 2016 at 2:59 AM, Philip
Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank"></a><a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> The
option we use is to have a
custom memory manager,
override the
getPointerToNamedFunction
function, and provide the
pointer to the external
function at link time. The
inttoptr scheme works fairly
well, but it does make for
some pretty ugly and
sometimes hard to analyze
IR. I recommend leaving
everything symbolic until
link time if you can.<br>
<br>
Philip
<div>
<div><br>
<br>
<div>On 03/28/2016 06:33
PM, Russell Wallace
via llvm-dev wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">That
seems to work,
thanks! The specific
code I ended up with
to call int64_t
print(int64_t) looks
like:
<div><br>
</div>
<div>
<div> auto
f =
builder.CreateIntToPtr(</div>
<div>
ConstantInt::get(builder.getInt64Ty(),
uintptr_t(print)),</div>
<div>
PointerType::getUnqual(FunctionType::get(</div>
<div>
builder.getInt64Ty(),
{builder.getInt64Ty()},
false)));</div>
<div>
return
builder.CreateCall(f,
args);</div>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Mon, Mar 28, 2016
at 1:40 PM,
Caldarale, Charles
R <span dir="ltr"><<a href="mailto:Chuck.Caldarale@unisys.com" target="_blank"></a><a href="mailto:Chuck.Caldarale@unisys.com" target="_blank">Chuck.Caldarale@unisys.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>
From: llvm-dev
[mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank"></a><a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>]<br>
> On Behalf
Of Russell
Wallace via
llvm-dev<br>
> Subject:
[llvm-dev] JIT
compiler and
calls to
existing
functions<br>
<div>
<div><br>
> In the
context of a
JIT compiler,
what's the
recommended
way to
generate a
call to an<br>
> existing
function, that
is, not one
that you are
generating
on-the-fly
with LLVM, but<br>
> one
that's already
linked into
your program?
For example
the cosine
function (from
the<br>
> standard
math library);
the
Kaleidoscope
tutorial
recommends
looking it up
by name with<br>
>
dlsym("cos"),
but it seems
to me that it
should be
possible to
use a more
efficient and<br>
> portable
solution that
takes
advantage of
the fact that
you already
have an actual
pointer<br>
> to cos,
even if you
haven't linked
with debugging
symbols.<br>
<br>
</div>
</div>
Perhaps not the
most elegant,
but we simply
use the
IRBuilder.CreateIntToPtr()
method to
construct the
Callee argument
for
IRBuilder.CreateCall().
The first
argument for
CreateIntToPtr()
comes from
ConstantInt::get(I64,
uintptr_t(ptr)),
while the second
is a function
type pointer
defined by using
PointerType::get()
on the result of
FunctionType::get()
with the
appropriate
function
signature.<br>
<br>
- Chuck<br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div>