<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<base href="x-msg://42696/"><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree. I’d like to see the interface be set up to enable clients to implement something like Elena described, but I was imagining a much simpler implementation
in the LLVM trunk code.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Jim Grosbach [mailto:grosbach@apple.com]
<br>
<b>Sent:</b> Monday, July 30, 2012 10:17 AM<br>
<b>To:</b> Demikhovsky, Elena<br>
<b>Cc:</b> Kaylor, Andrew; llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> Re: [LLVMdev] RFC: MCJIT enhancements - Object Caching<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This sounds interesting, but strikes me as significantly outside the scope of the MCJIT itself. That is, this is the sort of thing a client application or framework would build on top of the MCJIT.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Jim<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Jul 30, 2012, at 6:20 AM, "Demikhovsky, Elena" <<a href="mailto:elena.demikhovsky@intel.com">elena.demikhovsky@intel.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I have some vision about Object Caching.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">A client, which is interested in object caching, will need some help from compiler and LLVM side. The object file, located on disk, should contain information
that allows to decide – rebuild or not rebuild.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The client (a backend engine, which translates IR to JIT) compares data from object file, found on disk and module IR.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The information that object file may contain I call “Signature”. It can be stored in “.comment” section.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Signature includes:</span><o:p></o:p></p>
</div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Name
of source file, full path. (It may be .ll or .cl or .cpp or any other extension, the compilation was started from)</span><o:p></o:p></p>
</div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Time
stamp of the source file.</span><o:p></o:p></p>
</div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Name
and version of the compiler.</span><o:p></o:p></p>
</div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Compilation
flags.</span><o:p></o:p></p>
</div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Environment
variables (all or those who affect compilation process)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The compiler can generate this data and put it in metadata.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If we’ll take Intel OpenCL product, the clang can generate this special metadata. MCJIT, while building an object file, will compose a “ .comment” with a signature,
described above.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">Ø</span><span style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I
would like to introduce a mechanism whereby JITed objects could be cached and loaded from cache at a future time. It seems that the caching should logically be performed transparently within the MCJIT engine, but it also seems that the caching mechanism will
need to be provided by the client (or at least under client control). I think that the best way to accomplish this is the introduce a new interface (ObjectManager?), similar to the memory manager, that can be specified by the client and used by the MCJIT
engine. What I have in mind is that when MCJIT is about to compile a module, it will first check with the ObjectManager to see if a pre-compiled image is available. If so, it will simply pass that image to the RuntimeDyld for loading. If not, it will compile
as usual. Likewise, after compilation (but before loading) MCJIT would offer the compiled image to the ObjectManager and the ObjectManager could save the image to a file cache (or whatever).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><i><span style="color:teal">- Elena</span></i></b><o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span class="apple-converted-space"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> </span></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><a href="mailto:llvmdev-bounces@cs.uiuc.edu"><span style="color:purple">llvmdev-bounces@cs.uiuc.edu</span></a><span class="apple-converted-space"> </span>[mailto:llvmdev-<a href="mailto:bounces@cs.uiuc.edu"><span style="color:purple">bounces@cs.uiuc.edu</span></a>]<span class="apple-converted-space"> </span><b>On
Behalf Of<span class="apple-converted-space"> </span></b>Kaylor, Andrew<br>
<b>Sent:</b><span class="apple-converted-space"> </span>Wednesday, July 25, 2012 01:25<br>
<b>To:</b><span class="apple-converted-space"> </span><a href="mailto:llvmdev@cs.uiuc.edu"><span style="color:purple">llvmdev@cs.uiuc.edu</span></a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>[LLVMdev] RFC: MCJIT enhancements</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Following up and expanding on an earlier conversation, I'd like to discuss making several non-trivial changes to the MCJIT engine and related objects. There
may be some interdependencies between these changes, but I think that they can be logically grouped as follows:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">* Lazy module compilation</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">* Enhance the JIT memory manager interface to enable section-based memory protection</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">* Clean up object/memory ownership problems</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">* Introduce a mechanism for caching generated objects</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">* Support JIT events for MCJIT</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">* Support ELF generation on Windows</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Now let me expand on each of these a bit.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">---------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Lazy compilation</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">---------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Right now a Module is passed to the EngineBuilder::create call and is compiled immediately within the MCJIT constructor. I don't believe it is possible to
perform lazy compilation on a per function basis as was done in the legacy JIT interface, but there's no reason that module compilation and loading can't be deferred until a function is requested. I think this is a fairly straight-forward and non-controversial
change.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">----------------------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Memory manager interface</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">----------------------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The memory manager changes are a bit more complicated. In the current MCJIT implementation, MCJIT clients may specify a memory manager through the EngineBuilder
and this memory manager will be passed along to the MCJIT engine. The JITMemoryManager interface was originally created to suit the needs of the legacy JIT engine. As the MCJIT engine has come into existence, its memory needs have been somewhat wedged in
to the old JITMemoryManager interface. The result has been that there are effectively two interfaces existing side-by-side in the same abstract base class and implementations will typically only support one or the other set of functions. This is further
complicated by the RuntimeDyldMemoryManager, which doesn't inherit from the JITMemoryManager but does share a subset of functions and is implemented as a wrapper around the client-supplied memory manager in the current MCJIT code. There's also an MCJITmemoryManager
class which derives from RuntimeDyld and is used by MCJIT but isn't exposed to the client at all.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I'd like to see this situation cleaned up as we move forward with a way for the client to specify an MCJITMemoryManager directly and a separation of the legacy
memory manager interface from the new interface. In addition, I'd like the new memory manager interface to be extended with the functions that the RuntimeDyld needs to manage setting of section-specific permissions including non-writable code and read-only
data.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">----------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Object ownership</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">----------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Within the current MCJIT implementation there are a number of ugly cross dependencies in object/memory life cycle, making the MCJIT/RuntimeDyld/JITMemoryManager
relationship fragile and very dependent upon a particular order of object destruction. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In the current implementation, the buffer into which code is generated is owned by the MCJIT component, but when sections from the generated code are loaded,
they are loaded into memory owned by the JITMemoryManager. During object loading, an ObjectFile is created within the RuntimeDyld which references both of these buffers. The situation is further compilicated in the case where the RuntimeDyldELF object attempts
to register the generated object with GDB, because the GDB-interface requires a reference to both memory buffers. The GDB_required references are currently maintained in an ObjectImage instance which is held by RuntimeDyldELF.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">For those who are visually oriented, I am attaching a diagram which shows the object relationships.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I would like to change this by introducing an ObjectBuffer which would be allocated by the MCJIT object at compilation time and then passed to the RuntimeDyld::loadObject.
RuntimeDyld::loadObject would hand this ObjectBuffer off to the new ObjectImage instance (which it already creates today). The ObjectImage would be returned from the RuntimeDyld::loadObject to MCJIT and MCJIT would own that object.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Again, a diagram is attached.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Object caching</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I would like to introduce a mechanism whereby JITed objects could be cached and loaded from cache at a future time. It seems that the caching should logically
be performed transparently within the MCJIT engine, but it also seems that the caching mechanism will need to be provided by the client (or at least under client control). I think that the best way to accomplish this is the introduce a new interface (ObjectManager?),
similar to the memory manager, that can be specified by the client and used by the MCJIT engine. What I have in mind is that when MCJIT is about to compile a module, it will first check with the ObjectManager to see if a pre-compiled image is available.
If so, it will simply pass that image to the RuntimeDyld for loading. If not, it will compile as usual. Likewise, after compilation (but before loading) MCJIT would offer the compiled image to the ObjectManager and the ObjectManager could save the image
to a file cache (or whatever).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-----------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MCJIT Events</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-----------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The legacy JIT interface supported a JITEventListener interface that would provide notification when new functions were JITed. That interface was used to enable
source-level profiling of JITed code. There is currently no equivalent for the MCJIT engine. I'd like to correct that.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In order to get to the function level, some code somewhere will need to parse the format-specific object code that is generated. I think that it makes sense
for that to be pushed to the event listener itself since some listeners may be satisfied with the raw object itself as input.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Most of the support necessary to parse object images to obtain source-level debug information is already present in LLVM somewhere, though not all of it is
handily exposed through interfaces in the include tree. In order to implement a default event listener that provides the basic functionality of the existing JIT event listeners, some extensions to the existing DIContext and related DebugInfo classes will
be necessary. The development of an interface to expose more DWARF information may prove worthy of its own discussion, as it would also enable better testing, but for now I'll just mention it as a requirement here.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It may make sense to subsume the object loading event under the ObjectManager interface described in the "object caching" section above rather than overloading
the existing JITEventListener interface within MCJIT, as the other events in that interface don't properly apply to MCJIT.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-------------------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">ELF Support on Windows</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-------------------------------</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">There are various reasons that it would be nice to be able to support generation of ELF objects on Windows through the MCJIT interface, one of which is that
it would allow users to debug JITed code with GDB (i.e. MinGW). There was a proposal by Eli Bendersky to enable ELF generation on Windows by extending the target triple handling. We have been using that approach, and it works. However, at the time it was
proposed there seemed to be a general feeling that it would be preferable to have a general way to specify a non-default object format for any platform rather than a Windows/ELF-specific extension.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The original discussion can be found here:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136053.html"><span style="font-size:12.0pt;color:purple">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136053.html</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Unfortunately, I don't believe a consensus was ever reached as to what the correct way to implement this would be. I'd like to re-open that discussion now
so that we can find a solution that would be generally accepted for inclusion in LLVM.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We can, of course, discuss any and all of these in more details as the implementation unfolds, but I wanted to get all of it out there first as a sort of road
map to get general input on the overall direction of things in the MCJIT space.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks to all who took the time to read this, and thank you in advance for your feedback.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Andy</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Courier New"">---------------------------------------------------------------------<br>
Intel Israel (74) Limited<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</span><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu"><span style="color:purple">LLVMdev@cs.uiuc.edu</span></a><span class="apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu"><span style="color:purple">http://llvm.cs.uiuc.edu</span></a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"><span style="color:purple">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</span></a><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>