Chapter 1: Understanding LLVM
JavaScript is one of the most popular programming languages. However, JavaScript has two main disadvantages:
- Unpredictable performance
JavaScript executes inside the environment and runtime provided by JavaScript engines. There are various JavaScript engines (V8, WebKit, and Gecko). All of them were built differently and run the same JavaScript code in a different way. Added to that, JavaScript is dynamically typed. This means JavaScript engines should guess the type while executing the JavaScript code. These factors lead to unpredictable performance in JavaScript execution. The optimizations for one type of JavaScript engine may cause undesirable side effects on other types of JavaScript engines. This leads to unpredictable performance.
- Bundle size
The JavaScript engine waits until it downloads the entire JavaScript file before parsing and executing. The larger the JavaScript file, the longer the wait will be. This will degrade your application's performance. Bundlers such as webpack help to minimize the bundle size. But when your application grows, the bundle size grows exponentially.
Is there a tool that provides native performance and comes in a much smaller size? Yes, WebAssembly.
WebAssembly is the future of web and node development. WebAssembly is statically typed and precompiled, and thus it provides better performance than JavaScript. Precompilation of the binary provides an option to generate tiny binary bundles. WebAssembly allows languages such as Rust, C, and C++ to be compiled into binaries that run inside the JavaScript engine along with JavaScript. All WebAssembly compilers use LLVM underneath to convert the native code into WebAssembly binary code. Thus, it is important to understand what LLVM is and how it works.
In this chapter, we will learn what the various components of a compiler are and how they work. Then, we will explore what LLVM is and how it helps the compiled languages. Finally, we will see how the LLVM compiler compiles native code. We will cover the following topics in this chapter:
- Understanding compilers
- Exploring LLVM
- LLVM in action
Technical requirements
We will make use of Clang, which is a compiler that compiles C/C++ code into native code.
For Linux and Mac users, Clang should be available out of the box.
For Windows users, Clang can be installed from the following link: https://llvm.org/docs/GettingStarted.html?highlight=installing%20clang%20windows#getting-the-source-code-and-building-llvm to install Clang.
You can find the code files present in this chapter on GitHub at https://github.com/PacktPublishing/Practical-WebAssembly
Understanding compilers
Programming languages are broadly classified into compiled and interpreted languages.
In the compiled world, the code is first compiled into target machine code. This process of converting the code into binary is called compilation. The software program that converts the code into target machine code is called a compiler. During the compilation, the compiler runs a series of checks, passes, and validation on the code written and generates an efficient and optimized binary. A few examples of compiled languages are C, C++, and Rust.
In the interpreted world, the code is read and executed in a single pass. Since the compilation happens at runtime, the generated machine code is not as optimized as its compiled counterpart. Interpreted languages are significantly slower than compiled ones, but they provide dynamic typing and a smaller program size.
In this book, we will focus only on compiled languages.
Compiled languages
A compiler is a translator that translates source code into machine code (or in a more abstract way, converts the code from one programming language to another). A compiler is complicated because it should understand the language in which the source code is written (its syntax, semantics, and context); it should also understand the target machine code (its syntax, semantics, and context) and should create a representation that maps the source code into the target machine code.
A compiler has the following components:
- Frontend – The frontend is responsible for handling the source language.
- Optimizer – The optimizer is responsible for optimizing the code.
- Backend – The backend is responsible for handling the target language.

Figure 1.1 – Components of a compiler
Frontend
The frontend focuses on handling the source language. The frontend parses the code upon receiving it. The code is then checked for any grammar or syntax issues. After that, the code is converted (mapped) into an intermediate representation (IR). Consider IR as a format that represents the code that the compiler processes. The IR is the compiler's version of your code.
Optimizer
The second component in the compiler is the optimizer. This is optional, but as the name indicates, the optimizer analyzes the IR and transforms it into a much more efficient one. Few compilers have multiple IRs. The compiler efficiently optimizes the code on every pass over the IR. The optimizer is an IR-to-IR transformer. The optimizer analyzes, runs passes, and rewrites the IR. The optimizations here include removing redundant computations, eliminating dead code (code that cannot be reached), and various other optimizing options, which will be explored in future chapters. It is important to note that the optimizers need not be language-specific. Since they act on the IR, they can be built as a generic component and reused with multiple languages.
Backend
The backend focuses on producing the target language. The backend receives the generated (optimized) IR and converts it into another language (such as machine code). It is also possible to chain multiple backends that convert the code into some other languages. The backend is responsible for generating the target machine code from the IR. This machine code is the actual code that runs on the bare metal. In order to produce efficient machine code, the backend should understand the architecture in which the code is executed.
Machine code is a set of instructions that instructs the machine to store some values in registers and do some computation on them. For example, the generated machine code is responsible for efficiently storing a 64-bit number in 32-bit architecture in a free register (and things like that). The backend should understand the target environment to efficiently create a set of instructions and properly select and schedule the instructions to increase the performance of the application execution.
Compiler efficiency
The faster the execution, the better the performance.
The efficiency of the compiler depends on how it selects the instruction, allocates the register, and schedules the instruction execution in the given architecture. An instruction set is a set of operations supported by a processor, and this overall design is called an Instruction Set Architecture (ISA). The ISA is an abstract model of a computer and is often referred to as computer architecture. Various processors convert the ISA in different implementations. The different implementations may vary in performance. The ISA is an interface between the hardware and the software.
If you are implementing a new programming language and you want this language to be running on different architectures (or, more abstractly, different processors), then you should build the backend for each of these architectures/targets. But building these backends for every architecture is difficult and will take time, cost, and effort to embark on a language creation journey.
What if we create a common IR and build a compiler that converts this IR into machine code that runs efficiently on various architecture? Let's call this compiler a low-level virtual machine. Now, the role of your frontend in the compiler chain is just to convert the source code into an IR that is compatible with a low-level virtual machine (such as LLVM). Now, the general purpose of a low-level virtual machine is to be a common reusable component that maps the IR into native code for various targets. But the low-level virtual machine will only understand the common IR. This IR is called the LLVM IR and the compiler is called LLVM.
Exploring LLVM
LLVM is a part of the LLVM Project. The LLVM Project hosts compilers and toolchain technologies. The LLVM core is a part of the LLVM Project. The LLVM core is responsible for providing source- and target-independent optimization and for generating code for many CPU architectures. This enables language developers to just create a frontend that generates an LLVM-compatible IR or LLVM IR from the source language.
Did You Know?
LLVM is not an acronym. When the project was started as a research project, it meant Low-Level Virtual Machine. But later, it was decided to use the name as it is rather than as an acronym.
The main advantages of LLVM are as follows:
- LLVM uses a simple low-level language that looks similar to C.
- LLVM is strongly typed.
- LLVM has strictly defined semantics.
- LLVM has accurate and precise garbage collection.
- LLVM provides various optimizations that you can choose based on the requirement. It has aggressive, scalar, inter-procedural, simple-loop, and profile-driven optimizations.
- LLVM provides various compilation models. They are link time, install time, runtime, and offline.
- LLVM generates machine code for various target architectures.
- LLVM provides DWARF debugging information.
Note
DWARF is a debugging file format used by many compilers and debuggers to support source-level debugging. DWARF is architecture-independent and applicable to any processor or operating system. It uses a data structure called a Debugging Information Entry (DIE) to represent each variable, type, procedure, and so on.
If you want to explore more about DWARF, refer to http://dwarfstd.org/doc/Debugging%20using%20DWARF-2012.pdf.
Important Note
LLVM is not a single monolithic project. It is a collection of subprojects and other projects. These projects are used by various languages, such as Ruby, Python, Haskell, Rust, and D, for compilation.
Now that we have an understanding of compilers and LLVM, we will see how it is used.
LLVM in action
In this section, let's use LLVM's Clang compiler to compile native code into LLVM IR. This will give a better idea of how LLVM works and will be useful for understanding how the compilers use LLVM in future chapters.
We first create a C file called sum.c
and enter the following contents:
$ touch sum.c // sum.c unsigned sum(unsigned a, unsigned b) { return a + b; }
The sum.c
file contains a simple sum
function that takes in two unsigned integers and returns the sum of them. LLVM provides the Clang LLVM compiler to compile the C source code. In order to generate the LLVM IR, run the following command:
$ clang -S -O3 -emit-llvm sum.c
We provided the Clang compiler with the -S
, -O3
, and -emit-llvm
options:
- The
-S
option specifies for the compiler to only run the preprocess and compilation steps. - The
-O3
option specifies for the compiler to generate a well-optimized binary. - The
-emit-llvm
option specifies for the compiler to emit the LLVM IR while generating the machine code.
The preceding code will print out the following LLVM IR:
define i32 @sum(i32, i32) local_unnamed_addr #0 { %3 = add i32 %1, %0 ret i32 %3 }
The syntax of the LLVM IR is structurally much closer to C. The define
keyword defines the beginning of a function. Next to that is the return type of the function, i32
. Next, we have the name of the function, @sum
.
Important Note
Note the @
symbol there? LLVM uses @
to identify the global variables and function. It uses %
to identify the local variables.
After the function name, we state the types of the input argument (i32
in this case). The local_unnamed_addr
attribute indicates that the address is known not to be significant within the module. The variables in the LLVM IR are immutable. That is, once you define them, you cannot change them. So inside the `block`, we create a new local value, %3
, and assign it the value of add
. add
is an opcode that takes in the `type` of the arguments followed by the two arguments, %0
and %1
. %0
and %1
denote the first and second local variables. Finally, we return %3
with the ret
keyword followed by the `type`.
This IR is transformable; that is, the IR can be transformed from the textual representation into memory and then into actual bit code that run on the bare metal. Also, from bit code, you can transform them back to the textual representation.
Imagine that you are writing a new language. The success of the language depends on how versatile the language is at performing on various architectures. Generating optimized byte codes for various architectures (such as x86, ARM, and others) takes a long time and it is not easy. LLVM provides an easy way to achieve it. Instead of targeting the different architecture, create a compiler frontend that converts the source code into an LLVM compatible IR. Then, LLVM will convert the IR into efficient and optimized byte code that runs on any architecture.
Note
LLVM is an umbrella project. It has so many components that you could write a set of books on them. Covering the whole of LLVM and how to install and run them is beyond the scope of this book. If you are interested in learning more about various components of LLVM, how they work, and how to use them, then check out the website: https://llvm.org.
Summary
In this chapter, we have seen how compiled languages work and how LLVM helps to compile them. We have compiled a sample program with LLVM to understand how it works. In the next chapter, we'll explore Emscripten, a tool that converts C/C++ into a WebAssembly module. Emscripten uses the LLVM backend to do the compilation.