<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Philip Reames schrieb:<br>
</div>
<blockquote cite="mid:54B9988C.6070703@philipreames.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 01/16/2015 02:08 PM, Armin
Steinhoff wrote:<br>
</div>
<blockquote cite="mid:54B98BF1.8050003@steinhoff.de" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi Lang,<br>
<br>
Lang Hames schrieb:<br>
</div>
<blockquote
cite="mid:CALLttgr14eASd989Vdw_UG-=Rdq1rZwEA0_nzx3kz-rLSnbcPw@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Armin,
<div><br>
</div>
<div>> The MCJIT API can only be used once to JIT compile
external souces to excuteable code into the address space
of a running process.<br>
</div>
</div>
</blockquote>
<br>
That means: after the first successfull JIT compile it isn't
possible to do it again (within the same active process) ...
because of some resource issues.<br>
</blockquote>
Er, this is definitely something specific to your use case or
environment. I'm doing thousands of compiles in the same process
on an extremely regular basis with no problems. <br>
</blockquote>
<br>
Good to know ... I started 2 years ago and used the tool "lli" as an
JIT example, but didn't care about the atexit handling in details. <br>
Is in the meantime a documentation available about the "MCJIT API" ?<br>
I'm not a specialist for compiler construction ... so it is a PITA
for me to go through the djungle of class definitions (most of them
w/o any comments explaining their semantics).<br>
<br>
Is it not possible to develop a user interface for the JIT compile
API comparable to the user interface of e.g. CLANG ??<br>
<br>
Thanks so far<br>
<br>
Armin<br>
<br>
<br>
<blockquote cite="mid:54B9988C.6070703@philipreames.com" type="cite">
<blockquote cite="mid:54B98BF1.8050003@steinhoff.de" type="cite">
<br>
<blockquote
cite="mid:CALLttgr14eASd989Vdw_UG-=Rdq1rZwEA0_nzx3kz-rLSnbcPw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I'm not sure exactly what you mean
by "can only be used once" in this context. Regardless,
the new APIs are definitely designed to make it easier to
lead, unload and replace modules, and I hope they will
support a wider range of use cases off-the-shelf than
MCJIT does.</div>
</div>
</blockquote>
<br>
OK ... sound interesting, I will test it.<br>
<br>
<br>
Regards<br>
<br>
Armin <br>
<br>
<br>
<blockquote
cite="mid:CALLttgr14eASd989Vdw_UG-=Rdq1rZwEA0_nzx3kz-rLSnbcPw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Cheers,</div>
<div class="gmail_extra">Lang.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jan 16, 2015 at 2:41 AM,
Armin Steinhoff <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:armin@steinhoff.de" target="_blank">armin@steinhoff.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
Hi Lang,<br>
<br>
we are using the JIT API of TCC and the MCJIT
API in order to import external code into a
running control application process.<br>
<br>
The MCJIT API can only be used once to JIT compile
external souces to excuteable code into the
address space of a running process.<br>
<br>
Has your JIT API the same restriction ? It would
be very nice if your JIT API could provide a
similar functionalty as provided by TCC.<br>
<br>
Best Regards<br>
<br>
Armin<br>
<br>
<br>
Lang Hames schrieb:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span class="">
<div style="font-size:13px">Hi All,<br>
</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">The attached patch
(against r225842) contains some new JIT APIs
that I've been working on. I'm going to
start breaking it up, tidying it up, and
submitting patches to llvm-commits soon, but
while I'm working on that I thought I'd put
the whole patch out for the curious to start
playing around with and/or commenting on.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">The aim of these
new APIs is to cleanly support a wider range
of JIT use cases in LLVM, and to recover
some of the functionality lost when the
legacy JIT was removed. In particular, I
wanted to see if I could re-enable lazy
compilation while following MCJIT's design
philosophy of relying on the MC layer and
module-at-a-time compilation. The attached
patch goes some way to addressing these
aims, though there's a lot still to do.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">The 20,000 ft
overview, for those who want to get straight
to the code:</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">The new APIs are
not built on top of the MCJIT class, as I
didn't want a single class trying to be all
things to all people. Instead, the new APIs
consist of a set of software components for
building JITs. The idea is that you should
be able to take these off the shelf and
compose them reasonably easily to get the
behavior that you want. In the future I hope
that people who are working on LLVM-based
JITs, if they find this approach useful,
will contribute back components that they've
built locally and that they think would be
useful for a wider audience. As a
demonstration of the practicality of this
approach the attached patch contains a
class, MCJITReplacement, that composes some
of the components to re-create the behavior
of MCJIT. This works well enough to pass all
MCJIT regression and unit tests on Darwin,
and all but four regression tests on Linux.
The patch also contains the desired "new"
feature: Function-at-a-time lazy jitting in
roughly the style of the legacy JIT. The
attached lazydemo.tgz file contains a
program which composes the new JIT
components (including the lazy-jitting
component) to lazily execute bitcode. I've
tested this program on Darwin and it can run
non-trivial benchmark programs, e.g.
401.bzip2 from SPEC2006.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">These new APIs are
named after the motivating feature: On
Request Compilation, or ORC. I believe the
logo potential is outstanding. I'm picturing
an Orc riding a Dragon. If I'm honest this
was at least 45% of my motivation for doing
this project*.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">You'll find the
new headers in
llvm/include/llvm/ExecutionEngine/OrcJIT/*.h,
and the implementation files in
lib/ExecutionEngine/OrcJIT/*.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">I imagine there
will be a number of questions about the
design and implementation. I've tried to
preempt a few below, but please fire away
with anything I've left out.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Also, thanks to
Jim Grosbach, Michael Illseman, David
Blaikie, Pete Cooper, Eric Christopher, and
Louis Gerbarg for taking time out to review,
discuss and test this thing as I've worked
on it.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Cheers,</div>
<div style="font-size:13px">Lang.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Possible
questions:</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(1)</div>
<div style="font-size:13px">Q. Are you trying
to kill off MCJIT?</div>
<div style="font-size:13px">A. There are no
plans to remove MCJIT. The new APIs are
designed to live alongside it.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(2)</div>
<div style="font-size:13px">Q. What do "JIT
components" look like, and how do you
compose them?<br>
</div>
<div style="font-size:13px">A. The classes and
functions you'll find in OrcJIT/*.h fall
into two rough categories: Layers and
Utilities. Layers are classes that implement
a small common interface that makes them
easy to compose:<br>
</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">class SomeLayer {</div>
<div style="font-size:13px">private:</div>
</span>
<div style="font-size:13px">ÃÂ //
Implementation details</div>
<div style="font-size:13px">public:</div>
<div style="font-size:13px">ÃÂ //
Implementation details</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">ÃÂ typedef ???
Handle;</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">ÃÂ template
<typename ModuleSet></div>
<div style="font-size:13px">ÃÂ Handle
addModuleSet(ModuleSet&& Ms);</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">ÃÂ void
removeModuleSet(Handle H);</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">ÃÂ uint64_t
getSymbolAddress(StringRef Name, bool
ExportedSymbolsOnly);</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">ÃÂ uint64_t
lookupSymbolAddressIn(Handle H, StringRef
Name, bool ExportedSymbolsOnly);</div>
<span class="">
<div style="font-size:13px">};</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Layers are usually
designed to sit one-on-top-of-another, with
each doing some sort of useful work before
handing off to the layer below it. The
layers that are currently included in the
patch are the the CompileOnDemandLayer,
which breaks up modules and redirects calls
to not-yet-compiled functions back into the
JIT; the LazyEmitLayer, which defers adding
modules to the layer below until a symbol in
the module is actually requested; the
IRCompilingLayer, which compiles bitcode to
objects; and the ObjectLinkingLayer, which
links sets of objects in memory using
RuntimeDyld.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Utilities are
everything that's not a layer. Ideally the
heavy lifting is done by the utilities.
Layers just wrap certain uses-cases to make
them easy to compose.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Clients are free
to use utilities directly, or compose
layers, or implement new utilities or
layers.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(3)</div>
<div style="font-size:13px">Q. Why
"addModuleSet" rather than "addModule"?</div>
<div style="font-size:13px">A. Allowing
multiple modules to be passed around
together allows layers lower in the stack to
perform interesting optimizations. E.g.
direct calls between objects that are
allocated sufficiently close in memory. To
add a single Module you just add a
single-element set.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(4)</div>
<div style="font-size:13px">Q. What happened
to "finalize"?</div>
<div style="font-size:13px">A. In the Orc
APIs, getSymbolAddress automatically
finalizes as necessary before returning
addresses to the client. When you get an
address back from getSymbolAddress, that
address is ready to call.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(5)</div>
<div style="font-size:13px">Q. What does
"removeModuleSet" do?</div>
<div style="font-size:13px">A. It removes the
modules represented by the handle from the
JIT. The meaning of this is specific to each
layer, but generally speaking it means that
any memory allocated for those modules (and
their corresponding Objects, linked
sections, etc) has been freed, and the
symbols those modules provided are now
undefined. Calling getSymbolAddress for a
symbol that was defined in a module that has
been removed is expected to return '0'.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(5a)</div>
<div style="font-size:13px">Q. How are the
linked sections freed? RTDyldMemoryManager
doesn't have any "free.*Section" methods.</div>
<div style="font-size:13px">A. Each ModuleSet
gets its own RTDyldMemoryManager, and that
is destroyed when the module set is freed.
The choice of RTDyldMemoryManager is up to
the client, but the standard memory managers
will free the memory allocated for the
linked sections when they're destroyed.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(6)</div>
<div style="font-size:13px">Q. How does the
CompileOnDemand layer redirect calls to the
JIT?</div>
<div style="font-size:13px">A. It currently
uses double-indirection: Function bodies are
extracted into new modules, and the body of
the original function is replaced with an
indirect call to the extracted body. The
pointer for the indirect call is initialized
by the JIT to point at some inline assembly
which is injected into the module, and this
calls back in to the JIT to trigger
compilation of the extracted body. In the
future I plan to make the redirection
strategy a parameter of the CompileOnDemand
layer. Double-indirection is the safest: It
preserves function-pointer equality and
works with non-writable executable memory,
however there's no reason we couldn't use
single indirection (for extra speed where
pointer-equality isn't required), or
patchpoints (for clients who can allocate
writable/executable memory), or any
combination of the three. My intent is that
this should be up to the client.</div>
<div style="font-size:13px"><br>
</div>
</span>
<div style="font-size:13px">As a brief note:
it's worth noting that the CompileOnDemand
layer doesn't handle lazy compilation itself,
just lazy symbol resolution (i.e. symbols are
resolved on first call, not when compiling).
If you've put the CompileOnDemand layer on top
of the LazyEmitLayer then deferring symbol
lookup automatically defers compilation. (E.g.
You can remove the LazyEmitLayer in main.cpp
of the lazydemo and you'll get indirection and
callbacks, but no lazy compilation).ÃÂ </div>
<span class="">
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(7)</div>
<div style="font-size:13px">Q. Do the new APIs
support cross-target JITing like MCJIT does?</div>
<div style="font-size:13px">A. Yes.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(7.a)</div>
<div style="font-size:13px">Q. Do the new APIs
support cross-target (or cross process)
lazy-jitting?</div>
<div style="font-size:13px">A. Not yet, but
all that is required is for us to add a
small amount of runtime to the JIT'd process
to call back in to the JIT via some RPC
mechanism. There are no significant barriers
to implementing this that I'm aware of.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(8)</div>
<div style="font-size:13px">Q. Do any of the
components implement the ExecutionEngine
interface?</div>
<div style="font-size:13px">A. None of the
components do, but the MCJITReplacement
class does.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(9)</div>
<div style="font-size:13px">Q. Does this
address any of the long-standing issues with
MCJIT - Stackmap parsing? Debugging?
Thread-local-storage?</div>
<div style="font-size:13px">A. No, but it
doesn't get in the way either. These
features are still on the road-map (such as
it exists) and I'm hoping that the modular
nature of Orc will us to play around with
new features like this without any risk of
disturbing existing clients, and so allow us
to make faster progress.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">(10)</div>
<div style="font-size:13px">Q. Why is part X
of the patch (ugly | buggy | in the wrong
place) ?</div>
<div style="font-size:13px">A. I'm still
tidying the patch up - please save patch
specific feedback for for llvm-commits,
otherwise we'll get cross-talk between the
threads. The patches should be coming soon.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">---</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">As mentioned
above, I'm happy to answer further general
questions about what these APIs can do, or
where I see them going. Feedback on the
patch itself should be directed to the
llvm-commits list when I start posting
patches there for discussion.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">* Marketing
slogans abound: "Very MachO". "Some warts".
"Surprisingly friendly with ELF". "Not yet
on speaking terms with DWARF".</div>
</span></div>
<br>
<fieldset></fieldset>
<br>
<span class="">
<pre>_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a moz-do-not-send="true" href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a moz-do-not-send="true" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</span></blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>