summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorChris Lattner <sabre@nondot.org>2007-11-07 05:28:43 +0000
committerChris Lattner <sabre@nondot.org>2007-11-07 05:28:43 +0000
commita54c2019e1dae236e7e4736a88ab2b3b6543be19 (patch)
tree503a73655a9c9cfcd78b5a22425cae46538e2661 /docs
parent60a877d71351855d68491eeb123835ac7833a9e4 (diff)
downloadllvm-a54c2019e1dae236e7e4736a88ab2b3b6543be19.tar.gz
llvm-a54c2019e1dae236e7e4736a88ab2b3b6543be19.tar.bz2
llvm-a54c2019e1dae236e7e4736a88ab2b3b6543be19.tar.xz
minor edits
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43807 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs')
-rw-r--r--docs/tutorial/LangImpl4.html53
1 files changed, 28 insertions, 25 deletions
diff --git a/docs/tutorial/LangImpl4.html b/docs/tutorial/LangImpl4.html
index 11a6cc0177..04475e638e 100644
--- a/docs/tutorial/LangImpl4.html
+++ b/docs/tutorial/LangImpl4.html
@@ -39,8 +39,8 @@ Flow</li>
<div class="doc_text">
<p>Welcome to Chapter 4 of the "<a href="index.html">Implementing a language
-with LLVM</a>" tutorial. Parts 1-3 described the implementation of a simple
-language and included support for generating LLVM IR. This chapter describes
+with LLVM</a>" tutorial. Chapters 1-3 described the implementation of a simple
+language and added support for generating LLVM IR. This chapter describes
two new techniques: adding optimizer support to your language, and adding JIT
compiler support. This shows how to get nice efficient code for your
language.</p>
@@ -109,7 +109,7 @@ entry:
</pre>
</div>
-<p>Well, that was easy. :) In practice, we recommend always using
+<p>Well, that was easy :). In practice, we recommend always using
<tt>LLVMFoldingBuilder</tt> when generating code like this. It has no
"syntactic overhead" for its use (you don't have to uglify your compiler with
constant checks everywhere) and it can dramatically reduce the amount of
@@ -166,7 +166,8 @@ at link time, this can be a substantial portion of the whole program). It also
supports and includes "per-function" passes which just operate on a single
function at a time, without looking at other functions. For more information
on passes and how the get run, see the <a href="../WritingAnLLVMPass.html">How
-to Write a Pass</a> document.</p>
+to Write a Pass</a> document and the <a href="../Passes.html">List of LLVM
+Passes</a>.</p>
<p>For Kaleidoscope, we are currently generating functions on the fly, one at
a time, as the user types them in. We aren't shooting for the ultimate
@@ -212,7 +213,7 @@ add a set of optimizations to run. The code looks like this:</p>
that we're not going to take advantage of here, so I won't dive into what it is
all about.</p>
-<p>The meat of the matter is the definition of the "<tt>OurFPM</tt>". It
+<p>The meat of the matter is the definition of "<tt>OurFPM</tt>". It
requires a pointer to the <tt>Module</tt> (through the <tt>ModuleProvider</tt>)
to construct itself. Once it is set up, we use a series of "add" calls to add
a bunch of LLVM passes. The first pass is basically boilerplate, it adds a pass
@@ -222,10 +223,10 @@ which we will get to in the next section.</p>
<p>In this case, we choose to add 4 optimization passes. The passes we chose
here are a pretty standard set of "cleanup" optimizations that are useful for
-a wide variety of code. I won't delve into what they do, but believe that they
-are a good starting place.</p>
+a wide variety of code. I won't delve into what they do, but believe me that
+they are a good starting place :).</p>
-<p>Once the passmanager, is set up, we need to make use of it. We do this by
+<p>Once the PassManager is set up, we need to make use of it. We do this by
running it after our newly created function is constructed (in
<tt>FunctionAST::Codegen</tt>), but before it is returned to the client:</p>
@@ -238,8 +239,8 @@ running it after our newly created function is constructed (in
// Validate the generated code, checking for consistency.
verifyFunction(*TheFunction);
- // Optimize the function.
- TheFPM->run(*TheFunction);
+ <b>// Optimize the function.
+ TheFPM-&gt;run(*TheFunction);</b>
return TheFunction;
}
@@ -265,7 +266,7 @@ entry:
</div>
<p>As expected, we now get our nicely optimized code, saving a floating point
-add from the program.</p>
+add instruction from every execution of this function.</p>
<p>LLVM provides a wide variety of optimizations that can be used in certain
circumstances. Some <a href="../Passes.html">documentation about the various
@@ -286,15 +287,15 @@ executing it!</p>
<div class="doc_text">
-<p>Once the code is available in LLVM IR form a wide variety of tools can be
+<p>Code that is available in LLVM IR can have a wide variety of tools
applied to it. For example, you can run optimizations on it (as we did above),
you can dump it out in textual or binary forms, you can compile the code to an
assembly file (.s) for some target, or you can JIT compile it. The nice thing
-about the LLVM IR representation is that it is the common currency between many
-different parts of the compiler.
+about the LLVM IR representation is that it is the "common currency" between
+many different parts of the compiler.
</p>
-<p>In this chapter, we'll add JIT compiler support to our interpreter. The
+<p>In this section, we'll add JIT compiler support to our interpreter. The
basic idea that we want for Kaleidoscope is to have the user enter function
bodies as they do now, but immediately evaluate the top-level expressions they
type in. For example, if they type in "1 + 2;", we should evaluate and print
@@ -306,12 +307,12 @@ by adding a global variable and a call in <tt>main</tt>:</p>
<div class="doc_code">
<pre>
-static ExecutionEngine *TheExecutionEngine;
+<b>static ExecutionEngine *TheExecutionEngine;</b>
...
int main() {
..
- // Create the JIT.
- TheExecutionEngine = ExecutionEngine::create(TheModule);
+ <b>// Create the JIT.
+ TheExecutionEngine = ExecutionEngine::create(TheModule);</b>
..
}
</pre>
@@ -337,13 +338,13 @@ static void HandleTopLevelExpression() {
if (Function *LF = F-&gt;Codegen()) {
LF->dump(); // Dump the function for exposition purposes.
- // JIT the function, returning a function pointer.
+ <b>// JIT the function, returning a function pointer.
void *FPtr = TheExecutionEngine-&gt;getPointerToFunction(LF);
// Cast it to the right type (takes no arguments, returns a double) so we
// can call it as a native function.
double (*FP)() = (double (*)())FPtr;
- fprintf(stderr, "Evaluated to %f\n", FP());
+ fprintf(stderr, "Evaluated to %f\n", FP());</b>
}
</pre>
</div>
@@ -404,9 +405,9 @@ itself</em>.</p>
<p>What actually happened here is that the anonymous function is
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 for the "testfunc" function, and ends up in a stub that invokes
+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 reexecutes the call.</p>
+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
@@ -445,11 +446,13 @@ ready&gt; <b>foo(4.0);</b>
</pre>
</div>
-<p>Whoa, how does the JIT know about sin and cos? The answer is simple: in this
+<p>Whoa, how does the JIT know about sin and cos? The answer is surprisingly
+simple: in this
example, the JIT started execution of a function and got to a function call. It
realized that the function was not yet JIT compiled and invoked the standard set
of routines to resolve the function. In this case, there is no body defined
-for the function, so the JIT ended up calling "<tt>dlsym("sin")</tt>" on itself.
+for the function, so the JIT ended up calling "<tt>dlsym("sin")</tt>" on the
+Kaleidoscope process itself.
Since "<tt>sin</tt>" is defined within the JIT's address space, it simply
patches up calls in the module to call the libm version of <tt>sin</tt>
directly.</p>
@@ -479,7 +482,7 @@ double putchard(double X) {
<p>Now we can produce simple output to the console by using things like:
"<tt>extern putchard(x); putchard(120);</tt>", which prints a lowercase 'x' on
-the console (120 is the ascii code for 'x'). Similar code could be used to
+the console (120 is the ASCII code for 'x'). Similar code could be used to
implement file I/O, console input, and many other capabilities in
Kaleidoscope.</p>