<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">On 12/9/13 11:08 AM, Kaylor, Andrew
wrote:<br>
</div>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE56499200@ORSMSX104.amr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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. ...</p>
</div>
</blockquote>
Thank you for doing this. It's a good step to take and will help
both users and maintainers of the MCJIT infrastructure. <br>
<o:p></o:p>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE56499200@ORSMSX104.amr.corp.intel.com"
type="cite">
<div class="WordSection1"><o:p></o:p>
<p class="MsoNormal">4. Hot function replacement<o:p></o:p></p>
<p class="MsoNormal"> - client uses MCJIT to optimize
frequently executed code<o:p></o:p></p>
<p class="MsoNormal"> - example: WebKit<o:p></o:p></p>
<p class="MsoNormal"> - compilation time is not critical<o:p></o:p></p>
<p class="MsoNormal"> - execution speed is critical<o:p></o:p></p>
<p class="MsoNormal"> - steady state memory consumption is
very important<o:p></o:p></p>
<p class="MsoNormal"> - client handles pre-JIT
interpretation/execution<o:p></o:p></p>
<p class="MsoNormal"> - MCJIT instances may be created as
needed<o:p></o:p></p>
<p class="MsoNormal"> - custom memory manager transfers code
memory ownership after compilation<o:p></o:p></p>
<p class="MsoNormal"> - MCJIT instance is deleted when no
longer needed<o:p></o:p></p>
<p class="MsoNormal"> - client handles function replacement
and lifetime management</p>
</div>
</blockquote>
This is our currently planned use. <br>
<br>
A couple of extra requirements:<br>
- Linking of declared function names to specific addresses provided
at generation time (e.g. getPointerToNamedFunction)<br>
- Ability to place generated code at a specific address (either via
allocation control, or relocation)<br>
- Multiple compiler threads (using different instances of MCJIT)
without underlying shared state protected by locks. -- Mentioned
elsewhere, just making it explicit for this use case.<br>
- Internal errors are cleanly reported to API consumer with internal
state restored to well defined "safe" state -- I'm aware this is
very much wishful thinking at the moment, but being able to recover
from bad compiles would be very nice to have. We're likely to
explore external sandboxing as well, but having good library support
would be useful. <br>
- Debugging Support:<br>
- IR is verified before optimization (by default or by option)<br>
- IR can be easily dumped during various optimization passes for
debugging. Assembly can be dumped. <br>
<br>
A clarification question:<br>
- Do you see MCJIT having any role in inlining decisions in this
mode? If so, there's a fair amount of extra support around inline
decision tracking to support external lifetime policies. We don't
strictly need this, but long term it would simplify our out of code
tree substantially. <br>
<br>
A few things that are currently on our wish list, but that we
haven't actually gotten to yet:<br>
- Accurate debug information (with full stack traces) - this has
been discussed previously on the list. Not sure it would require
much extra from the MCJIT infrastructure. <br>
- Profile guided optimization (e.g. guarded inlining, type profiles
for call sites, edge counters, etc..) - We haven't gotten to the
point of considering what parts of this would be in tree vs language
specific and thus external. It's also unclear how much this would
effect MCJIT directly. <br>
- Inline call caching - likely using the patch point mechanism
introduced by the Webkit guys. <br>
- We've thrown around ideas of a compile server process. This would
involve constraints similar to your (2). This hasn't made it past
brain storming yet.<br>
<br>
Yours,<br>
Philip<br>
<br>
</body>
</html>