<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Andy,<br>
<br>
Our use of MCJIT/old JIT in cling is very similar to what Yaron
and Keno described. We use clang to codegen C/C++ functions
incrementally. We need lazy compilation support and
'function-level' linking, too. Remapping of GlobalValues is also
important for our use case. We support function removal, i.e we
need to make LLVM IR and the JIT forget functions that were
executed. All that was possible with the old JIT architecture and
I hope it could be possible with the MCJIT.<br>
<br>
That said, I think we mostly fit in the #1 case.<br>
<br>
Vassil<br>
On 12/10/2013 06:46 AM, Yaron Keren wrote:<br>
</div>
<blockquote
cite="mid:CANa4zJr32JZ9ojcpsJXUHMvvXk=4DCR4J+MzE+pv3draHyBZRg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="rtl">
<div dir="ltr">Hi Andy,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">My use case is quite similar to what Keno
described. I am using clang + JIT to dynamically compile C++
functions generated in response to user interaction. Generated
functions may be unloaded or modified. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I would like to break down the old JIT code into
three major parts.<br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">1) The old JIT has its own code emitter, which
duplicates code from lib/MC and does not generate debug info
and other limitations.<br>
</div>
<div dir="ltr">2) The old JIT supports lazy compilation.</div>
<div dir="ltr">3) The old JIT has its own function-level
"dynamic linker"/memory manager, supporting function
replacement with low-overhead JMP stubs.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Now 1) is clearly a problem of code duplication.
I'm not sure why a different emitter was created for the JIT
but it would seem it's possible to reuse the lib/MC code just
like MCJIT does. 2) takes much code all over the JIT code and
at least for my use case it could just be removed.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">If 1) and 2) are solved and removed we are left
with the (relatively small) "dynamic linker"/hack code only.
I'd say the way this linker/loader works is much better fit
for use cases such as my and Keno's than a classic linker like
the ELF loader.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">The JIT linker works at function level rather
than module level, supports automatic stub generation and
relinking management. We could wrap functions in modules for
the ELF loader, handle the stubs ourselves etc but this is
tricky code as Keno said, requires hard-learned knowledge and
feels like teaching an elephant to dance. The ELF loader is
really designed for very different requirements.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I'd like to see the old JIT function-level
"dynamic linker" code preserved somehow as a ready alternative
to a "classic" linker, especially useful when used in
combination clang to dynamically run C/C++ functions.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Yaron<br>
</div>
<div dir="ltr"><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">2013/12/10 Keno Fischer <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:kfischer@college.harvard.edu"
target="_blank">kfischer@college.harvard.edu</a>></span></div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">With Julia, we're obviously very much in the
first use case. As you know, we pretty much have a working
version of Julia on top of MCJIT, but there's still a few
kinks to work out, which I'll talk about in a separate
email.
<div>
<br>
</div>
<div>One think which I remember you asking at the BOF is
what MCJIT currently can't do well that the old JIT did,
so I'd like to offer up an example. With the old JIT, I
used Clang to do dynamic code generation to interface to
C++ easily. Now you might argue that is either a problem
with clang or rather a misuse of clang, but I'd like to
think that we should keep the tools as flexible as
possible, so applications like this can emerge. With the
old JIT, I'd incrementally compile functions as Clang
added them to the Module, but with MCJIT that kind of
stuff is rather tricky. What I ended up doing was having
Clang emit into a shadow module that never gets
codegen'd and when a function is requested, pulling that
function and it's closure out of the shadow module into
the current MCJIT module. Perhaps functionality like
that should be more readily available in base LLVM to be
able to use MCJIT with clients not necessarily designed
for use with MCJIT.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>
<div class="h5">On Mon, Dec 9, 2013 at 1:08 PM,
Kaylor, Andrew <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:andrew.kaylor@intel.com"
target="_blank">andrew.kaylor@intel.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal">Below is an outline of
various usage models for MCJIT that I put
together based on conversations at last
month’s LLVM Developer Meeting. If you’re
using or thinking about using MCJIT and your
use case doesn’t seem to fit in one of the
categories below then either I didn’t talk
to you or I didn’t understand what you’re
doing.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">In any case, I’d like to
see this get worked into a shape suitable
for inclusion in the LLVM documentation. I
imagine it serving as a guide both to those
who are new to using MCJIT and to those who
are developing and maintaining MCJIT. If
you’re using MCJIT the latter (yes, the
latter) case is particularly important to
you right now as having your use case
properly represented in this document is the
best way to ensure that it is adequately
considered when changes are made to MCJIT
and when the decision is made as to when we
are ready to deprecate the old JIT engine
(probably in the 3.5 release, BTW).</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">So here’s what I’m asking
for: if you are currently using MCJIT or
considering using MCJIT, can you please find
the use case that best fits your program and
comment on how well the outline describes
it. If you understand what I’m saying below
but you see something that is missing,
please let me know. If you aren’t sure what
I’m saying or you don’t know how MCJIT might
address your particular issues, please let
me know that too. If you think my outline
is too sketchy and you need me to elaborate
before you can provide meaningful feedback,
please let me know about that. If you think
it’s the best piece of documentation you’ve
read all year and you can’t wait to read it
again, that’s good information too.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks in advance for any
and all feedback.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">-Andy</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">------------------------------------------------------------------------------------------</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Models for MCJIT use</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">1. Interactive dynamic
code generation</p>
<p class="MsoNormal"> - user types code
which is compiled as needed for execution</p>
<p class="MsoNormal"> - example:
Kaleidoscope</p>
<p class="MsoNormal"> - compilation speed
probably isn't critical</p>
<p class="MsoNormal"> - use one MCJIT
instance with many modules</p>
<p class="MsoNormal"> - create new modules
on compilation</p>
<p class="MsoNormal"> - MCJIT handles
linking between modules</p>
<p class="MsoNormal"> - external
references still need prototypes</p>
<p class="MsoNormal"> - we can at least
provide a module pass to automate it</p>
<p class="MsoNormal"> - memory overhead may
be an issue but MCJIT can fix that</p>
<p class="MsoNormal"> - see model 2 for
pre-defined library</p>
<p class="MsoNormal"> - if processing a
large script pre-optimize before passing
modules to MCJIT
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">2. Code generation for
external target execution</p>
<p class="MsoNormal"> - client generates
code to be injected into an external process</p>
<p class="MsoNormal"> - example: LLDB
expression evaluation</p>
<p class="MsoNormal"> - target may be
another local or remote</p>
<p class="MsoNormal"> - target architecture
may not match host architecture</p>
<p class="MsoNormal"> - may use one or more
instances of MCJIT (client preference)</p>
<p class="MsoNormal"> - MCJIT handles
address remapping on request</p>
<p class="MsoNormal"> - custom memory
manager handles code/data transfer</p>
<p class="MsoNormal"> - speed/memory
requirements may vary</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">3. Large pre-defined
module compilation and execution</p>
<p class="MsoNormal"> - code/IR is loaded
from disk and prepared for execution</p>
<p class="MsoNormal"> - example: Intel(R)
OpenCL SDK</p>
<p class="MsoNormal"> - compilation speed
matters but isn't critical</p>
<p class="MsoNormal"> - initial startup
time is somewhat important</p>
<p class="MsoNormal"> - execution speed is
critical</p>
<p class="MsoNormal"> - memory consumption
isn't an issue</p>
<p class="MsoNormal"> - tool integration
may be important</p>
<p class="MsoNormal"> - use one MCJIT
instance with multiple (but usually) few
modules</p>
<p class="MsoNormal"> - use object caching
for commonly used code</p>
<p class="MsoNormal"> - for very large,
sparsely used libraries pre-link modules</p>
<p class="MsoNormal"> - object and archive
support may be useful</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">4. Hot function
replacement</p>
<p class="MsoNormal"> - client uses MCJIT
to optimize frequently executed code</p>
<p class="MsoNormal"> - example: WebKit</p>
<p class="MsoNormal"> - compilation time is
not critical</p>
<p class="MsoNormal"> - execution speed is
critical</p>
<p class="MsoNormal"> - steady state memory
consumption is very important</p>
<p class="MsoNormal"> - client handles
pre-JIT interpretation/execution</p>
<p class="MsoNormal"> - MCJIT instances may
be created as needed</p>
<p class="MsoNormal"> - custom memory
manager transfers code memory ownership
after compilation</p>
<p class="MsoNormal"> - MCJIT instance is
deleted when no longer needed</p>
<p class="MsoNormal"> - client handles
function replacement and lifetime management</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">5. On demand "one-time"
execution</p>
<p class="MsoNormal"> - client provides a
library of code which is used by small,
disposable functions</p>
<p class="MsoNormal"> - example: database
query?</p>
<p class="MsoNormal"> - initial load time
isn't important</p>
<p class="MsoNormal"> - execution time is
critical</p>
<p class="MsoNormal"> - if library code is
fixed, load as shared library</p>
<p class="MsoNormal"> - if library code
must be generated use a separate instance of
MCJIT to hold the library</p>
<p class="MsoNormal"> - this instance
can support multiple modules</p>
<p class="MsoNormal"> - use a custom
memory manager to link with functions in
this module</p>
<p class="MsoNormal"> - object caching
and archive support may be useful in this
case</p>
<p class="MsoNormal"> - if inlining/lto is
more important than compile time keep
library in an IR module and pre-link just
before invoking MCJIT</p>
<p class="MsoNormal"> - create one instance
of MCJIT as needed and destroy after
execution</p>
</div>
</div>
<br>
</div>
</div>
<div class="im">_______________________________________________<br>
LLVM Developers mailing list<br>
<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><br>
<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><br>
<br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true" href="mailto:LLVMdev@cs.uiuc.edu">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><br>
<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><br>
<br>
</blockquote>
</div>
<br>
</div>
<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>