6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-09-24 23:28:41 +00:00
Code Issues Projects Releases Wiki Activity

Change the JIT to compile eagerly by default as agreed in

Browse Source 
http://llvm.org/PR5184, and beef up the comments to describe what both options
do and the risks of lazy compilation in the presence of threads.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85295 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Jeffrey Yasskin
2009-10-27 20:30:28 +00:00
parent 5f75cf511b
commit dc85724f70
8 changed files with 59 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/tutorial/LangImpl4.html
View File

@@ -388,24 +388,19 @@ entry:
</pre>
</div>
<p>This illustrates that we can now call user code, but there is something a bit subtle
going on here. Note that we only invoke the JIT on the anonymous functions
that <em>call testfunc</em>, but we never invoked it on <em>testfunc
</em>itself.</p>
<p>This illustrates that we can now call user code, but there is something a bit
subtle going on here. Note that we only invoke the JIT on the anonymous
functions that <em>call testfunc</em>, but we never invoked it
on <em>testfunc</em> itself. What actually happened here is that the JIT
scanned for all non-JIT'd functions transitively called from the anonymous
function and compiled all of them before returning
from <tt>getPointerToFunction()</tt>.</p>
<p>What actually happened here is that the anonymous function was
JIT'd when requested. When the Kaleidoscope app calls through the function
pointer that is returned, the anonymous function starts executing. It ends up
making the call to the "testfunc" function, and ends up in a stub that invokes
the JIT, lazily, on testfunc. Once the JIT finishes lazily compiling testfunc,
it returns and the code re-executes the call.</p>
<p>In summary, the JIT will lazily JIT code, on the fly, as it is needed. The
JIT provides a number of other more advanced interfaces for things like freeing
allocated machine code, rejit'ing functions to update them, etc. However, even
with this simple code, we get some surprisingly powerful capabilities - check
this out (I removed the dump of the anonymous functions, you should get the idea
by now :) :</p>
<p>The JIT provides a number of other more advanced interfaces for things like
freeing allocated machine code, rejit'ing functions to update them, etc.
However, even with this simple code, we get some surprisingly powerful
capabilities - check this out (I removed the dump of the anonymous functions,
you should get the idea by now :) :</p>
<div class="doc_code">
<pre>
@@ -453,8 +448,8 @@ directly.</p>
resolved. It allows you to establish explicit mappings between IR objects and
addresses (useful for LLVM global variables that you want to map to static
tables, for example), allows you to dynamically decide on the fly based on the
function name, and even allows you to have the JIT abort itself if any lazy
compilation is attempted.</p>
function name, and even allows you to have the JIT compile functions lazily the
first time they're called.</p>
<p>One interesting application of this is that we can now extend the language
by writing arbitrary C++ code to implement operations. For example, if we add:

29
docs/tutorial/OCamlLangImpl4.html
View File

@@ -406,22 +406,17 @@ entry:
<p>This illustrates that we can now call user code, but there is something a bit
subtle going on here. Note that we only invoke the JIT on the anonymous
functions that <em>call testfunc</em>, but we never invoked it on <em>testfunc
</em>itself.</p>
functions that <em>call testfunc</em>, but we never invoked it
on <em>testfunc</em> itself. What actually happened here is that the JIT
scanned for all non-JIT'd functions transitively called from the anonymous
function and compiled all of them before returning
from <tt>run_function</tt>.</p>
<p>What actually happened here is that the anonymous function was JIT'd when
requested. When the Kaleidoscope app calls through the function pointer that is
returned, the anonymous function starts executing. It ends up making the call
to the "testfunc" function, and ends up in a stub that invokes the JIT, lazily,
on testfunc. Once the JIT finishes lazily compiling testfunc,
it returns and the code re-executes the call.</p>
<p>In summary, the JIT will lazily JIT code, on the fly, as it is needed. The
JIT provides a number of other more advanced interfaces for things like freeing
allocated machine code, rejit'ing functions to update them, etc. However, even
with this simple code, we get some surprisingly powerful capabilities - check
this out (I removed the dump of the anonymous functions, you should get the idea
by now :) :</p>
<p>The JIT provides a number of other more advanced interfaces for things like
freeing allocated machine code, rejit'ing functions to update them, etc.
However, even with this simple code, we get some surprisingly powerful
capabilities - check this out (I removed the dump of the anonymous functions,
you should get the idea by now :) :</p>
<div class="doc_code">
<pre>
@@ -467,8 +462,8 @@ calls in the module to call the libm version of <tt>sin</tt> directly.</p>
get resolved. It allows you to establish explicit mappings between IR objects
and addresses (useful for LLVM global variables that you want to map to static
tables, for example), allows you to dynamically decide on the fly based on the
function name, and even allows you to have the JIT abort itself if any lazy
compilation is attempted.</p>
function name, and even allows you to have the JIT compile functions lazily the
first time they're called.</p>
<p>One interesting application of this is that we can now extend the language
by writing arbitrary C code to implement operations. For example, if we add: