<!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. For example, when compiling simple code,
we don't get obvious optimizations:</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 1.000000e+00, 2.000000e+00
%addtmp1 = add double %addtmp, %x
ret double %addtmp1
}
</pre>
</div>
<p>This code is a very, very literal transcription of the AST built by parsing
the input. As such, this transcription lacks optimizations like constant folding (we'd like to get "<tt>add x, 3.0</tt>" in the example above) as well as other more important
optimizations. Constant folding, 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 builder, it would be nice if the builder itself checked to see if there
was a constant folding opportunity when you call it. If so, it could just do
the constant fold and return the constant instead of creating an instruction.
This is exactly what the <tt>LLVMFoldingBuilder</tt> class does. Lets make one
change:
<div class="doc_code">
<pre>
static LLVMFoldingBuilder Builder;
</pre>
</div>
<p>All we did was switch from <tt>LLVMBuilder</tt> to
<tt>LLVMFoldingBuilder</tt>. Though we change no other code, we now have all of our
instructions implicitly constant folded without us having to do anything
about it. For example, the input above now compiles to:</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>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
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>LLVMFoldingBuilder</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".</