Welcome to Chapter 4 of the “Implementing a language with
LLVM” 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.

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 “addx,3.0” 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.

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 LLVMFoldingBuilder class does.

All we did was switch from LLVMBuilder to LLVMFoldingBuilder.
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:

Well, that was easy :). In practice, we recommend always using
LLVMFoldingBuilder 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).

On the other hand, the LLVMFoldingBuilder 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:

In this case, the LHS and RHS of the multiplication are the same value.
We’d really like to see this generate “tmp=x+3;result=tmp*tmp;”
instead of computing “x*3” twice.

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”.

LLVM provides many optimization passes, which do many different sorts of
things and have different tradeoffs. Unlike other systems, LLVM doesn’t
hold to the mistaken notion that one set of optimizations is right for
all languages and for all situations. LLVM allows a compiler implementor
to make complete decisions about what optimizations to use, in which
order, and in what situation.

As a concrete example, LLVM supports both “whole module” passes, which
look across as large of body of code as they can (often a whole file,
but if run 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 they are run, see the
How to Write a Pass document and the
List of LLVM Passes.

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 optimization experience in this setting, but we also want to
catch the easy and quick stuff where possible. As such, we will choose
to run a few per-function optimizations as the user types the function
in. If we wanted to make a “static Kaleidoscope compiler”, we would use
exactly the code we have now, except that we would defer running the
optimizer until the entire file has been parsed.

In order to get per-function optimizations going, we need to set up a
Llvm.PassManager to hold and
organize the LLVM optimizations that we want to run. Once we have that,
we can add a set of optimizations to run. The code looks like this:

(* Create the JIT. *)letthe_execution_engine=ExecutionEngine.createCodegen.the_moduleinletthe_fpm=PassManager.create_functionCodegen.the_modulein(* Set up the optimizer pipeline. Start with registering info about how the * target lays out data structures. *)DataLayout.add(ExecutionEngine.target_datathe_execution_engine)the_fpm;(* Do simple "peephole" optimizations and bit-twiddling optzn. *)add_instruction_combiningthe_fpm;(* reassociate expressions. *)add_reassociationthe_fpm;(* Eliminate Common SubExpressions. *)add_gvnthe_fpm;(* Simplify the control flow graph (deleting unreachable blocks, etc). *)add_cfg_simplificationthe_fpm;ignore(PassManager.initializethe_fpm);(* Run the main "interpreter loop" now. *)Toplevel.main_loopthe_fpmthe_execution_enginestream;

The meat of the matter here, is the definition of “the_fpm”. It
requires a pointer to the the_module 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 so that later
optimizations know how the data structures in the program are laid out.
The “the_execution_engine” variable is related to the JIT, which we
will get to in the next section.

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 me, they are a good starting place :).

Once the Llvm.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 Codegen.codegen_func), but before it is returned to the client:

As expected, we now get our nicely optimized code, saving a floating
point add instruction from every execution of this function.

LLVM provides a wide variety of optimizations that can be used in
certain circumstances. Some documentation about the various
passes is available, but it isn’t very complete.
Another good source of ideas can come from looking at the passes that
Clang runs to get started. The “opt” tool allows you to
experiment with passes from the command line, so you can see if they do
anything.

Now that we have reasonable code coming out of our front-end, lets talk
about executing it!

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.

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 out 3. If they define a function, they should
be able to call it from the command line.

In order to do this, we first declare and initialize the JIT. This is
done by adding a global variable and a call in main:

This creates an abstract “Execution Engine” which can be either a JIT
compiler or the LLVM interpreter. LLVM will automatically pick a JIT
compiler for you if one is available for your platform, otherwise it
will fall back to the interpreter.

Once the Llvm_executionengine.ExecutionEngine.t is created, the JIT
is ready to be used. There are a variety of APIs that are useful, but
the simplest one is the
“Llvm_executionengine.ExecutionEngine.run_function” function. This
method JIT compiles the specified LLVM Function and returns a function
pointer to the generated machine code. In our case, this means that we
can change the code that parses a top-level expression to look like
this:

(* Evaluate a top-level expression into an anonymous function. *)lete=Parser.parse_toplevelstreaminprint_endline"parsed a top-level expr";letthe_function=Codegen.codegen_functhe_fpmeindump_valuethe_function;(* JIT the function, returning a function pointer. *)letresult=ExecutionEngine.run_functionthe_function[||]the_execution_engineinprint_string"Evaluated to ";print_float(GenericValue.as_floatCodegen.double_typeresult);print_newline();

Recall that we compile top-level expressions into a self-contained LLVM
function that takes no arguments and returns the computed double.
Because the LLVM JIT compiler matches the native platform ABI, this
means that you can just cast the result pointer to a function pointer of
that type and call it directly. This means, there is no difference
between JIT compiled code and native machine code that is statically
linked into your application.

Well this looks like it is basically working. The dump of the function
shows the “no argument function that always returns double” that we
synthesize for each top level expression that is typed in. This
demonstrates very basic functionality, but can we do more?

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 call testfunc, but we never invoked it on
testfunc 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
run_function.

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 :) :

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 “dlsym("sin")” on the Kaleidoscope
process itself. Since “sin” is defined within the JIT’s address
space, it simply patches up calls in the module to call the libm version
of sin directly.

The LLVM JIT provides a number of interfaces (look in the
llvm_executionengine.mli file) for controlling how unknown functions
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
compile functions lazily the first time they’re called.

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:

Now we can produce simple output to the console by using things like:
“externputchard(x);putchard(120);”, which prints a lowercase ‘x’
on 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.

This completes the JIT and optimizer chapter of the Kaleidoscope
tutorial. At this point, we can compile a non-Turing-complete
programming language, optimize and JIT compile it in a user-driven way.
Next up we’ll look into extending the language with control flow
constructs, tackling some interesting LLVM IR
issues along the way.

(*===----------------------------------------------------------------------=== * Lexer Tokens *===----------------------------------------------------------------------===*)(* The lexer returns these 'Kwd' if it is an unknown character, otherwise one of * these others for known things. *)typetoken=(* commands *)|Def|Extern(* primary *)|Identofstring|Numberoffloat(* unknown *)|Kwdofchar

lexer.ml:

(*===----------------------------------------------------------------------=== * Lexer *===----------------------------------------------------------------------===*)letreclex=parser(* Skip any whitespace. *)|[<'(' '|'\n'|'\r'|'\t');stream>]->lexstream(* identifier: [a-zA-Z][a-zA-Z0-9] *)|[<'('A'..'Z'|'a'..'z'asc);stream>]->letbuffer=Buffer.create1inBuffer.add_charbufferc;lex_identbufferstream(* number: [0-9.]+ *)|[<'('0'..'9'asc);stream>]->letbuffer=Buffer.create1inBuffer.add_charbufferc;lex_numberbufferstream(* Comment until end of line. *)|[<'('#');stream>]->lex_commentstream(* Otherwise, just return the character as its ascii value. *)|[<'c;stream>]->[<'Token.Kwdc;lexstream>](* end of stream. *)|[<>]->[<>]andlex_numberbuffer=parser|[<'('0'..'9'|'.'asc);stream>]->Buffer.add_charbufferc;lex_numberbufferstream|[<stream=lex>]->[<'Token.Number(float_of_string(Buffer.contentsbuffer));stream>]andlex_identbuffer=parser|[<'('A'..'Z'|'a'..'z'|'0'..'9'asc);stream>]->Buffer.add_charbufferc;lex_identbufferstream|[<stream=lex>]->matchBuffer.contentsbufferwith|"def"->[<'Token.Def;stream>]|"extern"->[<'Token.Extern;stream>]|id->[<'Token.Identid;stream>]andlex_comment=parser|[<'('\n');stream=lex>]->stream|[<'c;e=lex_comment>]->e|[<>]->[<>]

(*===----------------------------------------------------------------------=== * Code Generation *===----------------------------------------------------------------------===*)openLlvmexceptionErrorofstringletcontext=global_context()letthe_module=create_modulecontext"my cool jit"letbuilder=buildercontextletnamed_values:(string,llvalue)Hashtbl.t=Hashtbl.create10letdouble_type=double_typecontextletreccodegen_expr=function|Ast.Numbern->const_floatdouble_typen|Ast.Variablename->(tryHashtbl.findnamed_valuesnamewith|Not_found->raise(Error"unknown variable name"))|Ast.Binary(op,lhs,rhs)->letlhs_val=codegen_exprlhsinletrhs_val=codegen_exprrhsinbeginmatchopwith|'+'->build_addlhs_valrhs_val"addtmp"builder|'-'->build_sublhs_valrhs_val"subtmp"builder|'*'->build_mullhs_valrhs_val"multmp"builder|'<'->(* Convert bool 0/1 to double 0.0 or 1.0 *)leti=build_fcmpFcmp.Ultlhs_valrhs_val"cmptmp"builderinbuild_uitofpidouble_type"booltmp"builder|_->raise(Error"invalid binary operator")end|Ast.Call(callee,args)->(* Look up the name in the module table. *)letcallee=matchlookup_functioncalleethe_modulewith|Somecallee->callee|None->raise(Error"unknown function referenced")inletparams=paramscalleein(* If argument mismatch error. *)ifArray.lengthparams==Array.lengthargsthen()elseraise(Error"incorrect # arguments passed");letargs=Array.mapcodegen_exprargsinbuild_callcalleeargs"calltmp"builderletcodegen_proto=function|Ast.Prototype(name,args)->(* Make the function type: double(double,double) etc. *)letdoubles=Array.make(Array.lengthargs)double_typeinletft=function_typedouble_typedoublesinletf=matchlookup_functionnamethe_modulewith|None->declare_functionnameftthe_module(* If 'f' conflicted, there was already something named 'name'. If it * has a body, don't allow redefinition or reextern. *)|Somef->(* If 'f' already has a body, reject this. *)ifblock_beginf<>At_endfthenraise(Error"redefinition of function");(* If 'f' took a different number of arguments, reject. *)ifelement_type(type_off)<>ftthenraise(Error"redefinition of function with different # args");fin(* Set names for all arguments. *)Array.iteri(funia->letn=args.(i)inset_value_namena;Hashtbl.addnamed_valuesna;)(paramsf);fletcodegen_functhe_fpm=function|Ast.Function(proto,body)->Hashtbl.clearnamed_values;letthe_function=codegen_protoprotoin(* Create a new basic block to start insertion into. *)letbb=append_blockcontext"entry"the_functioninposition_at_endbbbuilder;tryletret_val=codegen_exprbodyin(* Finish off the function. *)let_=build_retret_valbuilderin(* Validate the generated code, checking for consistency. *)Llvm_analysis.assert_valid_functionthe_function;(* Optimize the function. *)let_=PassManager.run_functionthe_functionthe_fpminthe_functionwithe->delete_functionthe_function;raisee