<div dir="ltr">Hi All,<div><br></div><div>For reasons already covered by Philip and others I prefer symbolic resolution, rather than baking pointers into the IR. If you go that route and you're using ORC you just need to add a line to your symbol resolver:</div><div><br></div><div><div><span style="font-family:monospace,monospace">auto Resolver = createLambdaResolver(</span><br></div><div><font face="monospace, monospace"> [&](const std::string &Name) {</font></div><div><font face="monospace, monospace"> if (auto Sym = findMangledSymbol(Name))</font></div><div><font face="monospace, monospace"> return RuntimeDyld::SymbolInfo(Sym.getAddress(), Sym.getFlags()); </font></div><div><font face="monospace, monospace" color="#cc0000"> if (Name == "sin")</font></div><div><font face="monospace, monospace" color="#cc0000"> return RuntimeDyld::SymbolInfo(</font></div><div><font face="monospace, monospace" color="#cc0000"> static_cast<uint64_t>(reinterpret_cast<uintptr_t>(&sin),</font></div><div><font face="monospace, monospace" color="#cc0000"> JITSymbolFlags::Exported); </font></div><div><font face="monospace, monospace"> return RuntimeDyld::SymbolInfo(nullptr); </font></div><div><font face="monospace, monospace"> },</font></div><div><font face="monospace, monospace"> [](const std::string &S) { return nullptr; }); </font></div><div><br></div></div><div>If you have a large number of in-process symbols you'd like to supply you can substitute a StringMap lookup.</div><div><br></div><div>See llvm/examples/Kaleidoscope/include/KaleidoscopeJIT.h.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 30, 2016 at 8:08 AM, Philip Reames via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">
We use an explicit relocation step to deal with this. We generate
code into a temporary memory location, then relocate it into a
reserved area of memory which is always within a small relative
offset of other interesting code. This allows us to get pc relative
calls. <br>
<br>
Philip<div><div class="h5"><br>
<br>
<div>On 03/30/2016 05:53 AM, Matt Godbolt
wrote:<br>
</div>
<blockquote type="cite">
<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><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"></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">
<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"></a><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>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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>
<br></blockquote></div><br></div>