677
|
1 |
% !TEX program = xelatex
|
539
|
2 |
\documentclass{article}
|
|
3 |
\usepackage{../style}
|
|
4 |
\usepackage{../langs}
|
|
5 |
\usepackage{../graphics}
|
|
6 |
\usepackage{../grammar}
|
677
|
7 |
%%\usepackage{multicol}
|
539
|
8 |
|
677
|
9 |
%%\newcommand{\dn}{\stackrel{\mbox{\scriptsize def}}{=}}
|
539
|
10 |
|
|
11 |
\begin{document}
|
677
|
12 |
\fnote{\copyright{} Christian Urban, King's College London, 2019}
|
539
|
13 |
|
|
14 |
|
677
|
15 |
\section*{Handout 9 (LLVM, SSA and CPS)}
|
539
|
16 |
|
678
|
17 |
Reflecting on our tiny compiler targetting the JVM, the code generation
|
|
18 |
part was actually not so hard, no? Pretty much just some post-traversal
|
|
19 |
of the abstract syntax tree, yes? One of the main reason for this ease is
|
|
20 |
that the JVM is a stack-based virtual machine and it is therefore not
|
|
21 |
hard to translate arithmetic expressions into a sequence of instructions
|
|
22 |
manipulating the stack. The problem is that ``real'' CPUs, although
|
|
23 |
supporting stack operations, are not really designed to be \emph{stack
|
|
24 |
machines}. The design of CPUs is more like, here is a chunk of
|
|
25 |
memory---compiler, or better compiler writers, do something with it.
|
|
26 |
Consequently, modern compilers need to go the extra mile in order to generate
|
|
27 |
code that is much easier and faster to process by CPUs.
|
|
28 |
|
539
|
29 |
|
677
|
30 |
Another reason why it makes sense to go the extra mile is that stack
|
|
31 |
instructions are very difficult to optimise---you cannot just re-arrange
|
|
32 |
instructions without messing about with what is calculated on the stack.
|
|
33 |
Also it is hard to find out if all the calculations on the stack are
|
|
34 |
actually necessary and not by chance dead code. The JVM has for all this
|
|
35 |
sophisticated machinery to make such ``high-level'' code still run fast,
|
678
|
36 |
but let's say that for the sake of argument we do not want to rely on
|
|
37 |
it. We want to generate fast code ourselves. This means we have to work
|
|
38 |
around the intricacies of what instructions CPUs can actually process.
|
|
39 |
To make this all tractable for this module, we target the LLVM
|
|
40 |
Intermediate Language. In this way we can take advantage of the tools
|
|
41 |
coming with LLVM. For example we do not have to worry about things like
|
|
42 |
register allocations.\bigskip
|
539
|
43 |
|
678
|
44 |
\noindent LLVM\footnote{\url{http://llvm.org}} is a beautiful example
|
|
45 |
that projects from Academia can make a difference in the world. LLVM
|
|
46 |
started in 2000 as a project by two researchers at the University of
|
|
47 |
Illinois at Urbana-Champaign. At the time the behemoth of compilers was
|
|
48 |
gcc with its myriad of front-ends for other languages (e.g.~Fortran,
|
|
49 |
Ada, Go, Objective-C, Pascal etc). The problem was that gcc morphed over
|
|
50 |
time into a monolithic gigantic piece of m\ldots ehm software, which you
|
|
51 |
could not mess about in an afternoon. In contrast, LLVM is designed to
|
|
52 |
be a modular suite of tools with which you could play around easily and
|
|
53 |
try out something new. LLVM became a big player once Apple hired one of
|
|
54 |
the original developers (I cannot remember the reason why Apple did not
|
|
55 |
want to use gcc, but maybe they were also just disgusted by its big
|
|
56 |
monolithic codebase). Anyway, LLVM is now the big player and gcc is more
|
|
57 |
or less legacy. This does not mean that programming languages like C and
|
|
58 |
C++ are dying out any time soon---they are nicely supported by LLVM.
|
539
|
59 |
|
678
|
60 |
Targetting the LLVM Intermediate Language, or Intermediate
|
|
61 |
Representation (short LLVM-IR), also means we can profit from the very
|
|
62 |
modular structure of the LLVM compiler and let for example the compiler
|
|
63 |
generate code for X86, or ARM etc. That means we can be agnostic about
|
|
64 |
where our code actually runs. However, what we have to do is to generate
|
|
65 |
code in \emph{Static Single-Assignment} format (short SSA), because that
|
|
66 |
is what the LLVM-IR expects from us. LLVM-IR is the intermediate format
|
|
67 |
that LLVM uses for doing cool things, like targetting strange
|
|
68 |
architectures, optimising code and allocating memory efficiently.
|
539
|
69 |
|
678
|
70 |
The idea behind the SSA format is to use very simple variable
|
|
71 |
assignments where every variable is assigned only once. The assignments
|
|
72 |
also need to be primitive in the sense that they can be just simple
|
|
73 |
operations like addition, multiplication, jumps, comparisons and so on.
|
|
74 |
An idealised snippet of a program in SSA is
|
539
|
75 |
|
677
|
76 |
\begin{lstlisting}[language=LLVM,numbers=none]
|
|
77 |
x := 1
|
|
78 |
y := 2
|
|
79 |
z := x + y
|
|
80 |
\end{lstlisting}
|
539
|
81 |
|
678
|
82 |
\noindent where every variable is used only once (we could not write
|
|
83 |
\texttt{x := x + y} in the last line for example). There are
|
|
84 |
sophisticated algorithms for imperative languages, like C, that
|
|
85 |
efficiently transform a high-level program into SSA format. But we can
|
|
86 |
ignore them here. We want to compile a functional language and there
|
|
87 |
things get much more interesting than just sophisticated. We will need
|
|
88 |
to have a look at CPS translations, where the CPS stands for
|
|
89 |
Continuation-Passing-Style---basically black programming art or
|
|
90 |
abracadabra programming. So sit tight.
|
539
|
91 |
|
678
|
92 |
\subsection*{LLVM-IR}
|
539
|
93 |
|
678
|
94 |
Before we start, lets first have a look at the \emph{LLVM Intermediate
|
|
95 |
Representation}. What is good about our simple Fun language is that it
|
|
96 |
basically only contains expressions (be they arithmetic expressions or
|
|
97 |
boolean expressions). The exception is function definitions. Luckily,
|
|
98 |
for them we can use the mechanism of defining functions in LLVM-IR. For
|
|
99 |
example the simple Fun program
|
539
|
100 |
|
|
101 |
|
677
|
102 |
\begin{lstlisting}[language=Scala,numbers=none]
|
678
|
103 |
def sqr(x) = x * x
|
677
|
104 |
\end{lstlisting}
|
539
|
105 |
|
677
|
106 |
\noindent
|
|
107 |
can be compiled into the following LLVM-IR function:
|
539
|
108 |
|
677
|
109 |
\begin{lstlisting}[language=LLVM]
|
678
|
110 |
define i32 @sqr(i32 %x) {
|
|
111 |
%tmp = mul i32 %x, %x
|
677
|
112 |
ret i32 %tmp
|
|
113 |
}
|
|
114 |
\end{lstlisting}
|
539
|
115 |
|
678
|
116 |
\noindent First to notice is that all variable names in the LLVM-IR are
|
|
117 |
prefixed by \texttt{\%}; function names need to be prefixed with @.
|
|
118 |
Also, the LLVM-IR is a fully typed language. The \texttt{i32} type stands
|
|
119 |
for a 32-bit integer. There are also types for 64-bit integers, chars
|
|
120 |
(\texttt{i8}), floats, arrays and even pointer types. In teh code above,
|
|
121 |
\texttt{sqr} takes an argument of type \texttt{i32} and produces a
|
|
122 |
result of type \texttt{i32}. Each arithmetic operation, like addition or
|
|
123 |
multiplication, are also prefixed with the type they operate on.
|
|
124 |
Obviously these types need to match up\ldots{} but since we have in our
|
|
125 |
programs only integers, \texttt{i32} everywhere will do.
|
539
|
126 |
|
678
|
127 |
Conveniently, you can use the program \texttt{lli}, which comes with LLVM, to interprete
|
|
128 |
programs written in the LLVM-IR. So you can easily check whether the
|
|
129 |
code you produced actually works. To get a running program that does
|
|
130 |
something interesting you need to add some boilerplate about printing out
|
|
131 |
numbers and a main-function that is the entrypoint for the program (see Figure~\ref{lli}).
|
|
132 |
|
|
133 |
\begin{figure}[t]
|
|
134 |
\lstinputlisting[language=LLVM]{../progs/sqr.ll}
|
|
135 |
\caption{\label{lli}}
|
|
136 |
\end{figure}
|
|
137 |
|
|
138 |
\begin{figure}[t]
|
|
139 |
\begin{lstlisting}[language=Scala,numbers=none]
|
|
140 |
abstract class Exp extends Serializable
|
|
141 |
abstract class BExp extends Serializable
|
|
142 |
abstract class Decl extends Serializable
|
|
143 |
|
|
144 |
case class Main(e: Exp) extends Decl
|
|
145 |
case class Def(name: String, args: List[String], body: Exp)
|
|
146 |
extends Decl
|
|
147 |
|
|
148 |
case class Call(name: String, args: List[Exp]) extends Exp
|
|
149 |
case class If(a: BExp, e1: Exp, e2: Exp) extends Exp
|
|
150 |
case class Write(e: Exp) extends Exp
|
|
151 |
case class Var(s: String) extends Exp
|
|
152 |
case class Num(i: Int) extends Exp
|
|
153 |
case class Aop(o: String, a1: Exp, a2: Exp) extends Exp
|
|
154 |
case class Sequence(e1: Exp, e2: Exp) extends Exp
|
|
155 |
case class Bop(o: String, a1: Exp, a2: Exp) extends BExp
|
|
156 |
\end{lstlisting}
|
|
157 |
\caption{Abstract syntax trees for the Fun language.\label{absfun}}
|
|
158 |
\end{figure}
|
|
159 |
|
|
160 |
|
|
161 |
|
|
162 |
\subsection*{CPS-Translations}
|
|
163 |
|
|
164 |
|
539
|
165 |
\end{document}
|
|
166 |
|
|
167 |
|
|
168 |
%%% Local Variables:
|
|
169 |
%%% mode: latex
|
|
170 |
%%% TeX-master: t
|
|
171 |
%%% End:
|