<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@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;}
@font-face
{font-family:Verdana;
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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</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=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If you really trying to avoid linking everything into a shared
library (easiest choice), consider splitting up the compilation into a few more
steps: <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'>1) Compile and optimize once as part of your build, target LLVM
bitcode instead of machine code<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>2) Ship .bc files out to each node<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>3) Fix-up call instructions in a BasicBlockPass, run JIT without
any/many additional IR optimizations enabled<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'>This won’t get you around all the optimization passes and
the like but it’s still pretty fast and a lot easier than trying to patch
a direct call in machine 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'>-n<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"'>
llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu] <b>On Behalf
Of </b>Shasank Chavan<br>
<b>Sent:</b> Friday, March 26, 2010 1:52 PM<br>
<b>To:</b> rnk@mit.edu<br>
<b>Cc:</b> llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> Re: [LLVMdev] Questions on llvm and jit<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>Hi Reid. Thanks for your
response. We will be running this code in different processes across
different nodes. Basically we have
thousands of "executor" processes that are solely
responsible for executing this code generated at compile-time across
partitioned data. Rather than each one of these processes invoking
the jit and compiling with full opts and all of that, we believe it may
be cheaper to do this once at compile-time and have the processes simply
point to it and execute. As for a dll, compiling, linking, sending over
the dll to the different nodes, and then calling into the dll with dlopen will
not be cheap to do, and for that reason we're avoiding it.<br>
<br>
So for all the reasons above, we prefer everything to be inlined where
possible, and, if need be, have a mechanism to fix up target addresses of call
instructions. I'm more familiar with ia64 than x86, and so it's a
learning process for me to understand how easy it is to do this. First
off, is there common code out there or in the dll that will allow me to walk
through x86 instructions in search for a call?<br>
<br>
Thanks again for your response.<br>
<br>
- Shasank<br>
<br>
> From: rnk@mit.edu<br>
> Date: Fri, 26 Mar 2010 11:51:24 -0400<br>
> Subject: Re: [LLVMdev] Questions on llvm and jit<br>
> To: shanko_chavano@hotmail.com<br>
> CC: llvmdev@cs.uiuc.edu<br>
> <br>
> On Tue, Mar 23, 2010 at 4:44 PM, Shasank Chavan<br>
> <shanko_chavano@hotmail.com> wrote:<br>
> > Hi. I have more questions regarding llvm and using it as a jit
for our<br>
> > purposes. Also, let me confess that I haven't actually used
llvm yet (I'm<br>
> > still prototyping using gnu's libjit). Some of the issues that
have come up<br>
> > from that work so far leads to me these questions:<br>
> ><br>
> > 1) We intend to use llvm as a jit in our expression compiler at
compile-time<br>
> > only. At runtime, the x86 code generated from the bitcode
compiler will be<br>
> > packed and sent to our runtime facility for execution. This
implies a need<br>
> > to fixup things like external function calls made in the function we<br>
> > generated at compile-time. So suppose a call to
"memcpy" is made in our<br>
> > function F. The target address for memcpy will need to fixed up
at runtime<br>
> > in the x86 code in memory to point to the actual memcpy available on
the<br>
> > system. Obviously we may have problems if memcpy is bound to a
different<br>
> > load module (i.e. c runtime), so we may instead fix up the call to
point to<br>
> > a wrapper call that's bounded to the app. The question is, is
it possible<br>
> > to walk through the x86 instructions in search for "call"
instructions to<br>
> > then fix up the target? Does llvm have a facility to walk
through the<br>
> > actual machine code instructions to do this?<br>
> ><br>
> > 2) Similarly to (1), any external calls made by llvm (e.g. calls to<br>
> > intrinsic functions) will either need to be fixed up (as discussed in
(1))<br>
> > or prevented all-together. Is there a way to inline all
intrinsic calls so<br>
> > that no calls are made other than those purposefully inserted by me.<br>
> > Similarly, if a branch table is generated for a switch statement,
where in<br>
> > memory will this sit relative to the generated x86 code for the
function?<br>
> > Will it be possible to copy both the function and the jump table
together<br>
> > into our memory buffer for packing and shipping to our runtime
facility?<br>
> > Will there be wasted space? Clearly the location of the jump
table is<br>
> > relevent in terms of ensuring that the branch target offsets are
correct<br>
> > within the function, and for that reason this all matters.<br>
> <br>
> Why do you need this? Where are you running the code being generated,<br>
> ie what is your "runtime facility"? Is it another process on the
same<br>
> system or another machine on the network?<br>
> <br>
> In this case it might be easier for you to compile and link a shared<br>
> library and then dlopen it in your runtime facility.<br>
> <br>
> > 3) I noticed with libjit that the reg-allocator and alias analysis
(assuming<br>
> > this exists in libjit) is not the best. I wonder if llvm will
have a<br>
> > problem. If I make the appropriate llvm calls to redundandly
load an<br>
> > integer of a pointer several times (e.g. (goo == *a) .... ....
(foo ==<br>
> > *a)), will llvm make every effort to reusue the temp created to store
*a<br>
> > initially in the second reference? I tried this out with the
llvm demo, and<br>
> > the C code generated automatically created a temp for the first load,
and<br>
> > then reused that temp in the secondary reference. I however
would not be<br>
> > making such calls - I instead would probably generate the memory reference<br>
> > twice, and expect llvm to optimize this. Is my expectation
correct?<br>
> <br>
> It should.<br>
> <br>
> Reid<o:p></o:p></span></p>
<div class=MsoNormal align=center style='text-align:center'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>
<hr size=2 width="100%" align=center>
</span></div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>Hotmail:
Trusted email with Microsoft’s powerful SPAM protection. <a
href="http://clk.atdmt.com/GBL/go/210850552/direct/01/" target="_new">Sign up
now.</a><o:p></o:p></span></p>
</div>
</body>
</html>