<font size=2 face="sans-serif">Hello Lang,</font><br><br><font size=2 face="sans-serif">Thanks again for the new version!</font><br><font size=2 face="sans-serif">I have a question -- when I try to compile
it by creating a new directory in llvm/examples/Kaleidoscope/Orc/ similar
to </font><br><font size=2 face="sans-serif">Fully_lazy dir I get the following error.
I appreciate your help to avoid this error. (I tried without success to
link with </font><tt><font size=3>LLVMipo</font></tt><font size=2 face="sans-serif">)</font><br><br><font size=2 face="sans-serif">Thanks again,</font><br><font size=2 face="sans-serif">Revital</font><br><br><font size=2 face="sans-serif">Linking CXX executable ../../../../bin/Kaleidoscope-Orc-fully_lazy_with_recompile</font><br><font size=2 face="sans-serif">CMakeFiles/Kaleidoscope-Orc-fully_lazy_with_recompile.dir/toy.cpp.o:
In function `KaleidoscopeJIT::KaleidoscopeJIT(SessionContext&)::{lambda(std::unique_ptr<llvm::Module,
std::default_delete<llvm::Module> >)#1}::operator()(std::unique_ptr<llvm::Module,
std::default_delete<llvm::Module> >) const':</font><br><font size=2 face="sans-serif">llvm/examples/Kaleidoscope/Orc/fully_lazy_with_recompile/toy.cpp:1184:
undefined reference to `llvm::PassManagerBuilder::PassManagerBuilder()'</font><br><font size=2 face="sans-serif">llvm/examples/Kaleidoscope/Orc/fully_lazy_with_recompile/toy.cpp:1187:
undefined reference to `llvm::PassManagerBuilder::populateFunctionPassManager(llvm::legacy::FunctionPassManager&)'</font><br><font size=2 face="sans-serif">llvm/examples/Kaleidoscope/Orc/fully_lazy_with_recompile/toy.cpp:1191:
undefined reference to `llvm::PassManagerBuilder::~PassManagerBuilder()'</font><br><font size=2 face="sans-serif">collect2: error: ld returned 1 exit
status</font><br><font size=2 face="sans-serif">gmake[3]: *** [bin/Kaleidoscope-Orc-fully_lazy_with_recompile]
Error 1</font><br><font size=2 face="sans-serif">gmake[2]: *** [examples/Kaleidoscope/Orc/fully_lazy_with_recompile/CMakeFiles/Kaleidoscope-Orc-fully_lazy_with_recompile.dir/all]
Error 2</font><br><font size=2 face="sans-serif">gmake[1]: *** [examples/Kaleidoscope/CMakeFiles/Kaleidoscope.dir/rule]
Error 2</font><br><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Lang Hames <lhames@gmail.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Revital1 Eres/Haifa/IBM@IBMIL,
LLVM Developers Mailing List <llvm-dev@lists.llvm.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">18/09/2015 09:47 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [LLVMdev]
Help with using LLVM to re-compile hot functions at run-time</font><br><hr noshade><br><br><br><font size=3>Hi Revital,</font><br><br><font size=3>Attached is a new version of the fully_lazy Orc Kaleidoscope
demo that has been extended to enable re-compilation at higher optimisation
levels, roughly following the scheme I outlined before.</font><br><br><font size=3>In the compile action for the callback, the initial IR
for each is transformed like this:</font><br><br><br><tt><font size=3>
unsigned foo_counter = 0;</font></tt><br><tt><font size=3>void foo$impl() {
void foo$impl() {</font></tt><font size=3> </font><tt><font size=3><br> // foo body -> if
(++foo_counter > 1000) {</font></tt><font size=3> </font><tt><font size=3><br>}
auto fooOpt = $recompile(&foo);</font></tt><font size=3> </font><tt><font size=3><br>
fooOpt();</font></tt><font size=3> </font><tt><font size=3><br>
}</font></tt><font size=3> </font><tt><font size=3><br>
// foo body</font></tt><font size=3> </font><tt><font size=3><br>
}</font></tt><br><br><font size=3>The key changes to make this work (which you can see by
diff'ing toy.cpp against the original fully_lazy version):</font><br><br><font size=3>1) New layers HotCompileLayer and HotIROptsLayer added.
These perform IR optimisation and code generation at higher optimisation
levels than the default layers.</font><br><font size=3>2) The symbol resolver function (not to be confused with
the resolver block) has been pulled out into its own function, createResolver,
so that it can be shared between optimised & non-optimized code. It
also resolves the "$recompile" function to a static method on
the KaleidoscopeJIT class itself.</font><br><font size=3>3) The lazy compile action now calls 'instrumentFunctions'
before adding the IR for cold functions to the JIT.</font><br><font size=3>4) The instrumentFunctions method injects the counter
code and call to recompile.</font><br><font size=3>5) The recompileHot method re-IRGens functions, then adds
them to the HotIROpts layer to generate more optimized versions. It then
updates the function-body pointer so that subsequent calls go to the optimised
version.</font><br><font size=3> </font><br><font size=3 face="Arial">This is a bit quick-and-dirty, but does work.
In the future I'll try to tidy this up and turn it into a new tutorial
chapter.</font><br><br><font size=3 face="Arial">Hope this helps!</font><br><br><font size=3 face="Arial">Cheers,</font><br><font size=3 face="Arial">Lang.</font><br><br><br><br><br><font size=3>On Wed, Sep 16, 2015 at 10:09 PM, Revital1 Eres <</font><a href=mailto:ERES@il.ibm.com target=_blank><font size=3 color=blue><u>ERES@il.ibm.com</u></font></a><font size=3>>
wrote:</font><br><font size=2 face="sans-serif">Hi Lang,</font><font size=3> <br></font><font size=2 face="sans-serif"><br>Many thanks!!! I just wanted to make sure you did not miss it...</font><font size=3><br></font><font size=2 face="sans-serif"><br>Thanks again!</font><font size=3> </font><font size=2 face="sans-serif"><br>Revital</font><font size=3> <br><br><br></font><font size=1 color=#5f5f5f face="sans-serif"><br>From: </font><font size=1 face="sans-serif">Lang
Hames <</font><a href=mailto:lhames@gmail.com target=_blank><font size=1 color=blue face="sans-serif"><u>lhames@gmail.com</u></font></a><font size=1 face="sans-serif">></font><font size=3></font><font size=1 color=#5f5f5f face="sans-serif"><br>To: </font><font size=1 face="sans-serif">Revital1
Eres/Haifa/IBM@IBMIL</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>Cc: </font><font size=1 face="sans-serif">LLVM
Developers Mailing List <</font><a href=mailto:llvmdev@cs.uiuc.edu target=_blank><font size=1 color=blue face="sans-serif"><u>llvmdev@cs.uiuc.edu</u></font></a><font size=1 face="sans-serif">></font><font size=3></font><font size=1 color=#5f5f5f face="sans-serif"><br>Date: </font><font size=1 face="sans-serif">17/09/2015
01:56 AM</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>Subject: </font><font size=1 face="sans-serif">Re:
[LLVMdev] Help with using LLVM to re-compile hot functions at run-time</font><font size=3><br></font><hr noshade><font size=3><br><br><br>Hi Revital, <br><br>Apologies for the delayed reply. <br><br>I'm working on some example code for how to do this. I'll try to post it
tomorrow. <br><br>Cheers, <br>Lang. <br><br>On Tue, Sep 8, 2015 at 12:23 AM, Revital1 Eres <</font><a href=mailto:ERES@il.ibm.com target=_blank><font size=3 color=blue><u>ERES@il.ibm.com</u></font></a><font size=3>>
wrote: <br>Hi Lang, <br><br>After spending some time debugging Kaleidoscope orc fully_lazy toy example
on <br>x86 I want to start implementing run-time optimizer as you suggested and
again <br>I highly appreciate your help. <br>For now I'll defer the target specific implementation to the end after
I'll have <br>the non target parts in place as I can run on x86 as a start. <br>Given a simple example of main function calling foo and bar functions;
<br>IIUC I should start from the IR level of this module which means that <br>ParseIRFile will be be first called on the IR of the program, is that right?
<br><br>I would like to make sure I understand your suggestion which is to insert
a new <br>layer that should be implemented on top of the CompileCallbackLayer in
order to <br>be able to call trigger_condition at the beginning of a function. <br>IIUC until the function (bar or foo) is optimized the call to foo and bar
will <br>go through the resolver (foo and bar will not be compiled from scratch
every <br>time we go through the resolver but rather execute the cached non optimized
<br>version after first compiled). The resolver will check trigger_condition
<br>to see if the cached non optimized version should be executed or a new
<br>optimizied version should be compiled and executed. <br>After the trigger_condition is true foo and bar will be compiled to generate
<br>their optimized version and this version will be executed directly from
now on <br>(not going through the resolver any more). Is that right? <br>Does this layer on top of the CompileCallbackLayer should be similar to
<br>class KaleidoscopeJIT? <br>I saw that in Kaleidoscope Orc's example the Lambda functions that are
added in <br>createLambdaResolver are been executed by the resolver before compiling
a call <br>so I assume that the trigger_condition should be added also by <br>createLambdaResolver so before compiling foo or bar the Lambda functions
<br>that are added by calling createLambdaResolver and contain trigger_condition
<br>will be executed, is that right? <br><br>IIUC in Kaleidoscope Orc's example the interpreter calls the addModule
upon <br>parsing call expression in HandleTopLevelExpression. <br>In my case I assume addModule be called for the module returned from <br>ParseIRFile, right? <br>In this case should calling getAddress on the whole module (the IR of all
<br>functions) will trigger calling the Lambda functions defined in <br>createLambdaResolver on foo and bar functions? Also - in Kaleidoscope orc
<br>example the execution of the function is done explicitly in <br>HandleTopLevelExpression after calling getAddress and its not clear to
me where <br>I should insert this in my case. <br><br>Thanks again, <br>Revital <br><br><br></font><font size=1 color=#5f5f5f face="sans-serif"><br><br>From: </font><font size=1 face="sans-serif">Lang
Hames <</font><a href=mailto:lhames@gmail.com target=_blank><font size=1 color=blue face="sans-serif"><u>lhames@gmail.com</u></font></a><font size=1 face="sans-serif">></font><font size=3></font><font size=1 color=#5f5f5f face="sans-serif"><br>To: </font><font size=1 face="sans-serif">Revital1
Eres/Haifa/IBM@IBMIL</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>Cc: </font><font size=1 face="sans-serif">LLVM
Developers Mailing List <</font><a href=mailto:llvmdev@cs.uiuc.edu target=_blank><font size=1 color=blue face="sans-serif"><u>llvmdev@cs.uiuc.edu</u></font></a><font size=1 face="sans-serif">></font><font size=3></font><font size=1 color=#5f5f5f face="sans-serif"><br>Date: </font><font size=1 face="sans-serif">28/07/2015
05:58 AM</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>Subject: </font><font size=1 face="sans-serif">Re:
[LLVMdev] Help with using LLVM to re-compile hot functions at run-time</font><font size=3><br></font><hr noshade><font size=3><br><br><br>Hi Revital, <br><br>What do you mean by "code cache"? Orc (and MCJIT) does have the
concept of an ObjectCache, which is a long-lived, potentially persistent,
compiled version of some IR. It's not a key component of the JIT though:
Most clients run without a cache attached and just JIT their code from
scratch in each session. <br><br>Recompilation is orthogonal to caching. There is no in-tree support for
recompilation yet. There are several ways that it could be supported, depending
on what security / performance trade-offs you're willing to make, and how
deep in to the LLVM code you want to get. As things stand at the moment
all function calls in the lazy JIT are indirected via function pointers.
We want to add support for patchable call-sites, but this hasn't been implemented
yet. The Indirect calls make recompilation reasonably easy: You could add
a transform layer on top of the CompileCallbackLayer which would modify
each function like this: </font><tt><font size=3><br><br>void foo$impl() { void foo$impl() {</font></tt><font size=3></font><tt><font size=3><br> // foo body -> if
(trigger_condition) {</font></tt><font size=3> </font><tt><font size=3><br>}
auto fooOpt = jit_recompile_hot(&foo);</font></tt><font size=3></font><tt><font size=3><br>
fooOpt();</font></tt><font size=3> </font><tt><font size=3><br>
}</font></tt><font size=3> </font><tt><font size=3><br>
// foo body</font></tt><font size=3> </font><tt><font size=3><br>
}</font></tt><font size=3> <br><br>You would implement the jit_recompile_hot function yourself in your JIT
and make it available to JIT'd code via the SymbolResolver. When the trigger
condition is met you'll get a call to recompile foo, at which point you:
(1) Add the IR for foo to a 2nd IRCompileLayer that has been configured
with a higher optimization level, (2) look up the address of the optimized
version of foo, and (3) update the function pointer for foo to point at
the optimized version. The process for patchable callsites should be fairly
similar once they're available, except that you'll trigger a call-site
update rather than rewriting a function pointer. <br><br>This neglects all sorts of fun details (threading, garbage collection of
old function implementations), but hopefully it gives you a place to start.
<br><br><br>Regarding laziness, as Hal mentioned you'll have to provide some target
support for PowerPC to support lazy compilation. For a rough guide you
can check out the X86_64 support code in llvm/include/llvm/ExecutionEngine/Orc/OrcTargetSupport.h
and llvm/lib/ExecutionEngine/Orc/OrcTargetSupport.cpp. <br><br>There are two methods that you'll need to implement: insertCompileCallbackTrampoline
and insertResolverBlock. These work together to enable lazy compilation.
Both of these methods inject blobs of target specific code in to the JIT
process. To do this (at least for now) I make use of a handy feature of
LLVM IR: You can write raw assembly code directly into a bitcode module
("module-level asm"). If you look at the X86 implementation of
each of these methods you'll see they're written in terms of string-streams
building up a string of assembly which will be handed off to the JIT to
compile like any other code. <br><br>The first blob that you need to be able to output is the resolver block.
The purpose of the resolver block is to save program state and call back
in to the JIT to trigger lazy compilation of a function. When the JIT is
done compiling the function it returns the address of the compiled function
to the resolver block, and the resolver block returns to the compiled function
(rather than its original return address). <br><br>Because all functions share the same resolver block, the JIT needs some
way to distinguish them, which is where the trampolines come in. The JIT
emits one trampoline per function and each trampoline just calls the resolver
block. The return address of the call in each trampoline provides the unique
address that the JIT associates with the to-be-compiled functions. The
CompileCallbackManager manages this association between trampolines and
functions for you, you just need to provide the resolver/trampoline primitives.
<br><br>In case it helps, here's what the output of all this looks like on X86.
Trampolines are trivial - they're emitted in blocks and proceeded by a
pointer to the resolver block: </font><tt><font size=3><br><br>module asm "Lorc_resolve_block_addr:"</font></tt><font size=3></font><tt><font size=3><br>module asm " .quad 140439143575560"</font></tt><font size=3></font><tt><font size=3><br>module asm "orc_jcc_0:"</font></tt><font size=3> </font><tt><font size=3><br>module asm " callq *Lorc_resolve_block_addr(%rip)"</font></tt><font size=3></font><tt><font size=3><br>module asm "orc_jcc_1:"</font></tt><font size=3> </font><tt><font size=3><br>module asm " callq *Lorc_resolve_block_addr(%rip)"</font></tt><font size=3></font><tt><font size=3><br>module asm "orc_jcc_2:"</font></tt><font size=3> </font><tt><font size=3><br>module asm " callq *Lorc_resolve_block_addr(%rip)"</font></tt><font size=3></font><tt><font size=3><br>...</font></tt><font size=3> <br><br><br>The resolver block is more complicated and I won't provide the full code
for it here. You can find it by running: </font><div align=center><tt><font size=3>lli -jit-kind=orc-lazy -orc-lazy-debug=mods-to-stderr
<hello_world.ll></font></tt></div><br><font size=3><br><br><br>and looking at the initial output. In pseudo-asm though, it looks like
this: </font><tt><font size=3><br><br>module asm "jit_callback_manager_addr:"</font></tt><font size=3></font><tt><font size=3><br>module asm " .quad 0x46fc190" // <- address of callback
manager object</font></tt><font size=3> </font><tt><font size=3><br>module asm "orc_resolver_block:"</font></tt><font size=3> </font><tt><font size=3><br>module asm " // save register state."</font></tt><font size=3></font><tt><font size=3><br>module asm " // load jit_callback_manager_addr into %rdi</font></tt><font size=3></font><tt><font size=3><br>module asm " // load the return address (from the trampoline
call) into %rsi</font></tt><font size=3> </font><tt><font size=3><br>module asm " // %rax = call jit(%rdi, %rsi)</font></tt><font size=3></font><tt><font size=3><br>module asm " // save %rax over the return address</font></tt><font size=3></font><tt><font size=3><br>module asm " // restore register state</font></tt><font size=3></font><tt><font size=3><br>module asm " // retq"</font></tt><font size=3> <br><br>So, that's a whirlwind intro to implementing lazy JITing support for a
new architecture in Orc. I'll try to answer any questions you have on the
topic, though I'm not familiar with PowerPC at all. If you're comfortable
with PowerPC assembly I think it should be possible to implement once you
grok the concepts. <br><br>Hope this helps! <br><br>Cheers, <br>Lang. <br><br><br>On Jul 26, 2015, at 11:17 PM, Revital1 Eres <</font><a href=mailto:ERES@il.ibm.com target=_blank><font size=3 color=blue><u>ERES@il.ibm.com</u></font></a><font size=3>>
wrote:</font><font size=2 face="sans-serif"><br><br>Hi Again,</font><font size=3> </font><font size=2 face="sans-serif"><br><br>I'm a little confused regarding what is the exact Orc's functions I should
use</font><font size=3> </font><font size=2 face="sans-serif"><br>in order to save the functions code in a code cache so it could be later</font><font size=3></font><font size=2 face="sans-serif"><br>replaced with different versions of it and I appreciate your help.</font><font size=3></font><font size=2 face="sans-serif"><br><br>Just a reminder I want to dynamically recompile the program based on profile</font><font size=3></font><font size=2 face="sans-serif"><br> collected at the run-time. I would like to start executing the program
from</font><font size=3> </font><font size=2 face="sans-serif"><br>the code-cache and at some point be able to replace a function body with
it's</font><font size=3> </font><font size=2 face="sans-serif"><br>new compiled version; this can be done by replacing the entry in the function</font><font size=3></font><font size=2 face="sans-serif"><br> code with a trampoline to It's new version so that future calls to
it will</font><font size=3> </font><font size=2 face="sans-serif"><br>call the new version code.</font><font size=3> </font><font size=2 face="sans-serif"><br><br>Does the CompileOnDemandLayer executes the program from a code cache <br>and holds pointers to the code of the functions it executes? I am compiling
for Power machine. <br>Is there a target specific pieces that I should implement for making Orc
work on Power?</font><font size=3> </font><font size=2 face="sans-serif"><br><br>Thanks again,</font><font size=3> </font><font size=2 face="sans-serif"><br>Revital</font><font size=3> <br><br></font><font size=1 color=#5f5f5f face="sans-serif"><br><br><br>From: </font><font size=1 face="sans-serif">Lang
Hames <</font><a href=mailto:lhames@gmail.com target=_blank><font size=1 color=blue face="sans-serif"><u>lhames@gmail.com</u></font></a><font size=1 face="sans-serif">></font><font size=3></font><font size=1 color=#5f5f5f face="sans-serif"><br>To: </font><font size=1 face="sans-serif">Revital1
Eres/Haifa/IBM@IBMIL</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>Cc: </font><font size=1 face="sans-serif">LLVM
Developers Mailing List <</font><a href=mailto:llvmdev@cs.uiuc.edu target=_blank><font size=1 color=blue face="sans-serif"><u>llvmdev@cs.uiuc.edu</u></font></a><font size=1 face="sans-serif">></font><font size=3></font><font size=1 color=#5f5f5f face="sans-serif"><br>Date: </font><font size=1 face="sans-serif">20/07/2015
08:41 PM</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>Subject: </font><font size=1 face="sans-serif">Re:
[LLVMdev] Help with using LLVM to re-compile hot functions at run-time</font><font size=3><br></font><hr noshade><font size=3><br><br><br>Hi Revital, <br><br>The CompileOnDemand layer is used by the lazy bitcode JIT in the lli tool.
You can find the code in llvm/tools/lli/OrcLazyJIT.* . <br><br>Cheers, <br>Lang. <br><br><br>On Mon, Jul 20, 2015 at 2:32 AM, Revital1 Eres <</font><a href=mailto:ERES@il.ibm.com target=_blank><font size=3 color=blue><u>ERES@il.ibm.com</u></font></a><font size=3>>
wrote: </font><font size=2 face="sans-serif"><br>Hello </font><font size=3>Lang</font><font size=2 face="sans-serif">,</font><font size=3></font><font size=2 face="sans-serif"><br><br>Thanks for your answer.</font><font size=3> </font><font size=2 face="sans-serif"><br><br>I am now looking for an example of the usage of CompileOnDemandLayer. Is
there an example available for that (could not find one in llvm/examples)?</font><font size=3></font><font size=2 face="sans-serif"><br><br>Thanks,</font><font size=3> </font><font size=2 face="sans-serif"><br>Revital</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br><br><br><br>From: </font><font size=1 face="sans-serif">Lang
Hames <</font><a href=mailto:lhames@gmail.com target=_blank><font size=1 color=blue face="sans-serif"><u>lhames@gmail.com</u></font></a><font size=1 face="sans-serif">></font><font size=3></font><font size=1 color=#5f5f5f face="sans-serif"><br>To: </font><font size=1 face="sans-serif">Revital1
Eres/Haifa/IBM@IBMIL</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>Cc: </font><font size=1 face="sans-serif">LLVM
Developers Mailing List <</font><a href=mailto:llvmdev@cs.uiuc.edu target=_blank><font size=1 color=blue face="sans-serif"><u>llvmdev@cs.uiuc.edu</u></font></a><font size=1 face="sans-serif">></font><font size=3></font><font size=1 color=#5f5f5f face="sans-serif"><br>Date: </font><font size=1 face="sans-serif">10/07/2015
12:10 AM</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>Subject: </font><font size=1 face="sans-serif">Re:
[LLVMdev] Help with using LLVM to re-compile hot functions at run-time</font><font size=3><br></font><hr noshade><font size=3><br><br><br>Hi Revital, <br><br>LLVM does have an IR interpreter, but I don't think it's maintained well
(or possibly at all). The interpreter is also not designed to interact
with the LLVM JITs. <br><br>We generally encourage people to just JIT LLVM IR, rather than interpreting
it. For the use-case you have described, you could JIT IR with no optimizations
to begin with, then re-JIT hot functions at a higher level. <br><br>The Orc JIT APIs (LLVM's newer JIT APIs) were written with this kind of
use-case in mind, and are probably a better fit for this than MCJIT. There
is no built-in hot-function detection or recompilation yet, but I think
this would be *fairly* easy to write in terms of Orc's callback API. <br><br>Cheers, <br>Lang. <br><br><br>On Thu, Jul 9, 2015 at 4:19 AM, Revital1 Eres <</font><a href=mailto:ERES@il.ibm.com target=_blank><font size=3 color=blue><u>ERES@il.ibm.com</u></font></a><font size=3>>
wrote: </font><font size=2 face="sans-serif"><br>Hello,</font><font size=3> </font><font size=2 face="sans-serif"><br><br>I am new to LLVM and a I appreciate your help with the following:</font><font size=3></font><font size=2 face="sans-serif"><br><br>I want to run the LLVM IR through virtual machine (LLVM interpreter?) and
jit</font><font size=3> </font><font size=2 face="sans-serif"><br>compile the hot functions (using MCJIT).</font><font size=3> </font><font size=2 face="sans-serif"><br><br>This task will require amongst other identifying the hot functions and
having a</font><font size=3> </font><font size=2 face="sans-serif"><br>code cache that should be patched with the native code of the functions
after</font><font size=3> </font><font size=2 face="sans-serif"><br>they are jitted.</font><font size=3> </font><font size=2 face="sans-serif"><br><br>I've read so far about MCJIT and lli however I have not seen that the LLVM
<br>interpreter can be used as a VM the way I was looking for; meaning</font><font size=3></font><font size=2 face="sans-serif"><br>execute the code one instruction at a time; have a profiling mode to <br>identify hot functions and call jit to compile the hot functions.</font><font size=3></font><font size=2 face="sans-serif"><br><br>I appreciate any advice/starting points for this project.</font><font size=3></font><font size=2 face="sans-serif"><br><br>Thanks,</font><font size=3> </font><font size=2 face="sans-serif"><br>Revital</font><font size=3> <br><br>_______________________________________________<br>LLVM Developers mailing list</font><font size=3 color=blue><u><br></u></font><a href=mailto:LLVMdev@cs.uiuc.edu target=_blank><font size=3 color=blue><u>LLVMdev@cs.uiuc.edu</u></font></a><font size=3>
</font><a href=http://llvm.cs.uiuc.edu/ target=_blank><font size=3 color=blue><u>http://llvm.cs.uiuc.edu</u></font></a><font size=3 color=blue><u><br></u></font><a href=http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev target=_blank><font size=3 color=blue><u>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</u></font></a><font size=3><br><br><br><br><br><br><br><br></font><br><font size=1 face="sans-serif">[attachment "fully_lazy_with_recompile.tgz"
deleted by Revital1 Eres/Haifa/IBM] </font><br><br><BR>