<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Kaleidoscope: Adding JIT and Optimizer Support</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="author" content="Chris Lattner">
<link rel="stylesheet" href="../llvm.css" type="text/css">
</head>
<body>
<div class="doc_title">Kaleidoscope: Adding JIT and Optimizer Support</div>
<ul>
<li><a href="index.html">Up to Tutorial Index</a></li>
<li>Chapter 4
<ol>
<li><a href="#intro">Chapter 4 Introduction</a></li>
<li><a href="#trivialconstfold">Trivial Constant Folding</a></li>
<li><a href="#optimizerpasses">LLVM Optimization Passes</a></li>
<li><a href="#jit">Adding a JIT Compiler</a></li>
<li><a href="#code">Full Code Listing</a></li>
</ol>
</li>
<li><a href="LangImpl5.html">Chapter 5</a>: Extending the Language: Control
Flow</li>
</ul>
<div class="doc_author">
<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="intro">Chapter 4 Introduction</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>Welcome to Chapter 4 of the "<a href="index.html">Implementing a language
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. These additions will demonstrate how to get nice, efficient code
for the Kaleidoscope language.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="trivialconstfold">Trivial Constant
Folding</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
Our demonstration for Chapter 3 is elegant and easy to extend. Unfortunately,
it does not produce wonderful code. The IRBuilder, however, does give us
obvious optimizations when compiling simple code:</p>
<div class="doc_code">
<pre>
ready> <b>def test(x) 1+2+x;</b>
Read function definition:
define double @test(double %x) {
entry:
%addtmp = add double 3.000000e+00, %x
ret double %addtmp
}
</pre>
</div>
<p>This code is not a literal transcription of the AST built by parsing the
input. That would be:
<div class="doc_code">
<pre>
ready> <b>def test(x) 1+2+x;</b>
Read function definition:
define double @test(double %x) {
entry:
%addtmp = add double 2.000000e+00, 1.000000e+00
%addtmp1 = add double %addtmp, %x
ret double %addtmp1
}
</pre>
</div>
<p>Constant folding, as seen above, in particular, is a very common and very
important optimization: so much so that many language implementors implement
constant folding support in their AST representation.</p>
<p>With LLVM, you don't need this support in the AST. Since all calls to build
LLVM IR go through the LLVM IR builder, the builder itself checked to see if
there was a constant folding opportunity when you call it. If so, it just does
the constant fold and return the constant instead of creating an instruction.
<p>Well, that was easy :). In practice, we recommend always using
<tt>IRBuilder</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
LLVM IR that is generated in some cases (particular for languages with a macro
preprocessor or that use a lot of constants).</p>
<p>On the other hand, the <tt>IRBuilder</tt> is limited by the fact
that it does all of its analysis inline with the code as it is built. If you
take a slightly more complex example:</p>
<div class="doc_code">
<pre>
ready> <b>def test(x) (1+2+x)*(x+(1+2));</b>
ready> Read function definition:
define double @test(double %x) {
entry:
%addtmp = add double 3.000000e+00, %x
%addtmp1 = add double %x, 3.000000e+00
%multmp = mul double %addtmp, %addtmp1
ret double %multmp
}
</pre>
</div>
<p>In this case, the LHS and RHS of the multiplication are the same value. We'd
really like to see this generate "<tt>tmp = x+3; result = tmp*tmp;</tt>" instead
of computing "<tt>x+3</tt>" twice.</p>
<p>Unfortunately, no amount of local analysis will be able to detect and correct
this. This requires two transformations: reassociation of expressions (to
make the add's lexically identical) and Common Subexpression Elimination (CSE)
to delete the redundant add instruction. Fortunately, LLVM provides a broad
range of optimizations that you can use, in the form of "passes".</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="optimizerpasses">LLVM Optimization
Passes</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>