Optimized Retargetable Compiler for Embedded
Processors – GCC vs LLVM
Lavinia Ghica
Development Tools - Compiler
Microchip Romania
Bucharest, Romania
lavinia.dragusin@gmail.com
Abstract— Retargetable compilers become more and more
popular as they are involved even in the processors design phase.
The reduced time-to-market period puts a challenge on optimized
retargetable compilers. An optimized retargetable compiler gives
a reliable feedback to tailor processors towards a certain
application domain. The first choice in choosing a retargetable
compiler may be an open-source one. This paper aims to
compare two well-known open-source compilers: GCC and
LLVM. The first is a mature compiler, retargeted for more than
100 processors, while the second is a new one, retargeted for less
than 10 processors, but built on a very promising approach, one
big plus being the latest release of Redhat (Linux operating
system) which replaced the previously used GCC with LLVM.
The paper compares the two compilers from both easiness of
retargetability and the target specific optimizations enablement.
Keywords— optimized retargetable compiler; GCC; LLVM;
retargetable code generation; retargetable optimizations;
I. Introduction
A retargetable compiler is a compiler that can be easily
modified to generate code for different processors. Optimizing
retargetable compilers are very common nowadays, when
time-to-market for new processors became shorter and shorter.
They bridge the gap between classic compilers and electronic
processor design. In this context, the compilers have a double
role: first, they are used in the design phase of the processor to
explore its capabilities and second, they are released with the
new processor as part of the build tools chain.
The concern regarding retargetable compilers is their lack
of machine-specific code optimization techniques, which
prevents them from achieving the highest code quality. While
this problem is partially inherent to the retargetable
compilation approach, it can be circumvented by designing
flexible, configurable code optimization techniques that apply
to many target architectures and defining an interface which
can configure the optimizations using the machine description
information.
The retargetable compilers are modular, compared to the
traditional ones, having target independent modules, but also
target specific modules, mainly in the backend.
978-1-4673-8200-7/15/$31.00 ©2015 European Union
103
Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 02,2024 at 02:04:14 UTC from IEEE Xplore. Restrictions apply.
Nicolae Tapus
Computer Science Department
“Politehnica” University of Bucharest
Bucharest, Romania
ntapus@cs.pub.ro
The scope of this paper is to analyze two open-source
compilers: GCC, a mature retargetable compiler, and LLVM,
a new retargetable compiler, built on different concepts. The
GNU (GCC) compiler is one of the most widely used C/C++
compilers in the world. It is the basic build tool for building all
EmbeddedLinux and Android systems, as well as all desktop
or server Linux operating systems and their applications. The
GNU compiler is also used to build many commercial real-
time operating systems, such as those from Enea, QNX,
WindRiver and more.
Chapter 2 gives an overview of the machine description
representation for GCC and LLVM, figuring out the pluses
and minuses of each one. Chapter 3 discusses the compilers
construction and analyzes the code generation phase. Chapter
4 presents the two approaches for target specific optimizations
(e.g. register allocation) and the interaction between the
machine description and the optimization interrogations. This
chapter also underlines the possibility of adding a new target
specific optimization and estimates the effort of this task.
Chapter 5 focuses on object code generation. Chapter 6 makes
a final analysis and concludes.
Each chapter presents first the GCC approach and then the
LLVM one, just for maturity reasons.
II. Machine Description
Representation
The mechanism of GCC machine descriptions has been
quite successful as demonstrated by a wide variety of targets
for which GCC was retargeted. The Gnu Compiler Collection
uses a retargetable compilation model which is adapted to a
given target by reading a description of the target and
instantiating the machine dependent parts of the generated
compiler.
The first step in the retargeting process is to understand the
architecture of the target microprocessor. The key points in
understanding are the register file (general purpose registers
and special purpose registers - if any), the pipeline model of
 the processor (are there hazards, or stalls, or forwarding
network), and the instruction set (is it orthogonal). The second
step in the retargeting process is to define the ABI (application
binary interface). The ABI covers details like sizes, layout,
alignment of data types, defines calling conventions (how
arguments are passed to functions, the layout of the stack
frame, and register usage conventions). The third and final
step in the retargeting process is to define three key files that
will describe the microprocessor and its operating
environment to GCC. These three files are the target machine
macro file (machine.h), the machine description file
(machine.md), and a third file containing helper functions for
the previous two files (machine.c). However, at first look, the
machine descriptions are difficult to read, construct, maintain,
and enhance[11]. They require specifying instruction patterns
using Register Transfer Language (RTL) templates,
employing a mechanism which is verbose, repetitive and
requires a lot of details. Below is a typical RTL template from
MIPS machine description (addsi3).
Fig. 1. GCC – Example of instruction description
The RTL template uses RTL operators set and plus; the
former represents an assignment. Operator match_operand
matches an operand using a mode (SI for single integer), a
predicate (register_operand), and constraint strings ("=r", "r"
and "r"). Given a GIMPLE statement a = b + c, first an RTL
statement is generated and then the assembly statement is
generated eventually.
On many machines, the numbered registers are not all
equivalent. For example, certain registers may not be allowed
for indexed addressing; certain registers may not be allowed in
some instructions. These machine restrictions are described to
the compiler using register classes[10].
A register class is defined by giving each class a name and
saying which of the registers belong to it. Then, register
classes are detailed. They should be allowed as operands to
particular instruction patterns.
In general, each register will belong to several classes. In
fact, one class must be named ALL_REGS and contain all the
registers. Another class must be named NO_REGS and
contain no registers. Often the union of two classes will be
another class; however, this is not required[10].
One of the classes must be named GENERAL_REGS.
There is nothing special about the name (it is just a
convention), but the operand constraint letters ‘r’ and ‘g’
specify this class. If there is no difference between
GENERAL_REGS and ALL_REGS, GENERAL_REGS can
be defined as a macro which expands to ALL_REGS.
978-1-4673-8200-7/15/$31.00 ©2015 European Union
104
Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 02,2024 at 02:04:14 UTC from IEEE Xplore. Restrictions apply.
The way classes other than GENERAL_REGS are
specified in operand constraints is through machine-dependent
operand constraint letters. You can define such letters to
correspond to various classes, then use them in operand
constraints.
In GCC the register description should have the narrowest
register classes for allocatable registers, so that each class
either has no subclasses, or that for some mode, the move cost
between registers within the class is cheaper than moving a
register in the class to or from memory.
If an instruction (or a set of instructions) accepts registers
from two classes, a new class is defined as the union of the
two. For example, if an instruction allows either a floating
point (coprocessor) register or a general register for a certain
operand, you should define a
class FLOAT_OR_GENERAL_REGS which includes both of
them. Otherwise you will get suboptimal code, or even
internal compiler errors when reload cannot find a register in
the class computed via reg_class_subunion.
The machine description register information has certain
redundant information about the register classes: for each
class, it specifies which classes contain it and which ones are
contained in it; and for each pair of classes, the largest class
contained in their union. This allows the compiler to build a
class hierarchy and to check overlappings.
When a value occupying several consecutive registers is
expected in a certain class, all the respective registers must
belong to that class. Therefore, register classes cannot be used
to enforce a requirement for a register pair to start with an
even-numbered register. The way to specify this requirement
is with HARD_REGNO_MODE_OK.
LLVM describes 3 classes of instructions: L-type
instructions, which are generally associated with memory
operations, A-type instructions for arithmetic operations, and
J-type instructions that are typically used when altering
control flow (i.e. jumps).
A target description is done in a declarative domain-
specific language (a set of .td files) processed by the tblgen
tool. Each description file is completed by a .cpp file. For
example RegisterInfo.td has as pair RegisterInfo.cpp, which is
used to describe the register file of the target and any
interactions between the registers. Physical registers (those
that actually exist in the target description) are unique small
numbers, and virtual registers are generally large. Note that
register #0 is reserved as a flag value.
Each register in the processor description has an
associated TargetRegisterDesc entry, which provides a textual
name for the register (used for assembly output and debugging
dumps) and a set of aliases (used to indicate whether one
register overlaps with another).
Each register class contains sets of registers that have the
same properties (for example, they are all 32-bit integer
registers). Each SSA virtual register created by the instruction
selector has an associated register class. When the register
allocator runs, it replaces virtual registers with a physical
register in the set.

Fig. 2. LLVM – Machine Description through compiler
The TargetInstrInfo class is used to describe the machine
instructions supported by the target. It is essentially an array
of TargetInstrDescriptor objects, each of which describes one
instruction the target supports. Descriptors define
characteristics like the mnemonic for the opcode, the number
of operands, the list of implicit register uses and defs, whether
the instruction has certain target-independent properties
(accesses memory, is commutable, etc), and holds any target-
specific flags.
III. Code Generation
GCC uses a modified version of the Davidson Fraser
model of compilation [1]. This contrasts with the traditional
Aho Ullman model [2] which performs instruction selection
over optimized machine independent intermediate
representation (IR). In order to ensure the quality of generated
code, instruction selection in Aho Ullman model is performed
using cost based tree tiling [3] that tries to cover a Subject
Tree in the IR with instructions that minimize the cost using a
set of Transformer Trees.
The Davidson Fraser model advocates simple instruction
selection and optimizes the selected instructions. An expander
generates a naive machine dependent code using a set of
transformer tree (most often RTL trees) by employing simpler
structure based tiling. The final code is produced by a
recognizer that identifies the instructions (Inst) corresponding
to the register transfers representing the intermediate code.
Retargeting a compiler in Davidson Fraser model requires
rewriting the expander and the recognizer which employ
simple algorithms [4]. A generic optimizer for machine
dependent code is possible because of the following key idea:
When computations are expressed in the form of allowable
register transfers, although the actual register transfer
statements are machine dependent, their form is machine
independent [5].
One optimization performed during code generation is
merging comparison, as seen in Fig3.
In LLVM, Code Generation or Instruction Selection is the
process of translating LLVM code presented to the code
978-1-4673-8200-7/15/$31.00 ©2015 European Union
105
Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 02,2024 at 02:04:14 UTC from IEEE Xplore. Restrictions apply.
generator into target-specific machine instructions. There are
several well-known ways to do this in the literature. LLVM
uses a SelectionDAG based instruction selector.
if (i>=5) && (i<=10) becomes
(i-5)<=10
Fig. 3. GCC – Optimization during Code Generation
Portions of the DAG instruction selector are generated
from the target description (*.td) files. The LLVM goal is, for
the entire instruction selector, to be generated from
these .td files, though currently there are still things that
require custom C++ code.
The SelectionDAG provides an abstraction for code
representation in a way that is amenable to instruction
selection using automatic techniques (e.g. dynamic-
programming based optimal pattern matching selectors). It is
also well-suited to other phases of code generation; in
particular, instruction scheduling (SelectionDAG’s are very
close to scheduling DAGs post-selection). Additionally, the
SelectionDAG provides a host representation where a large
variety of very low level (but target-
independent) optimizations may be performed; ones which
require extensive information about the instructions efficiently
supported by the target.
The SelectionDAG is a Directed-Acyclic-Graph whose
nodes are instances of the SDNode class. The primary payload
of the SDNode is its operation code (Opcode) that indicates
what operation the node performs and the operands to the
operation. The various operation node types are described at
the top of
the include/llvm/CodeGen/SelectionDAGNodes.h file.
A SelectionDAG node contains the following information:
• Opcode. This is an integer that identifies the
instruction represented by the node.
• Results (definitions). While most instructions produce
exactly one result, some may either define several
values (e. g., operations with side effects, combined
division/modulo instructions) or no value at all (e. g.,
branch instructions). The node object keeps a list of
the value types for all of its results.
• Operands (uses). Every SDNode keeps a record of all
other nodes upon which it has a dependency.
A SelectionDAG has designated “Entry” and “Root”
nodes. The Entry node is always a marker node with an
Opcode of ISD::EntryToken. The Root node is the final side-
effecting node in the token chain. For example, in a single
basic block function it would be the return node.
One important concept for SelectionDAGs is the notion of
a “legal” vs. “illegal” DAG. A legal DAG for a target is one
that only uses supported operations and supported types. On a
32-bit PowerPC, for example, a DAG with a value of type i1,
i8, i16, or i64 would be illegal, as would a DAG that uses a
SREM or UREM operation. The legalize-types and legalize-
 operations phases are responsible for turning an illegal DAG
into a legal DAG.
The backend class targetTargetLowering, a subclass of
TargetLowering, offers a two-fold functionality. On the one
hand, it provides its superclass with target-specific
information, including:
• the alignment of machine functions (2 bytes)
• all value types natively supported by the target
machine, and, for each type, the register class that has
been defined for it
• the exact binary representation of boolean values
(true: 1, false: 0)
The problem with TableGen is that some of its uses are so
complex (and instruction selection, as we'll shortly see, is one
of the worst offenders) that it's easy to forget how simple the
idea is in its core. The LLVM developers realized a long time
ago that a lot of repetitive code has to be written for each new
target. Take a machine instruction, for instance. An instruction
is being used in code generation, in the assembler, in the
disassembler, in optimizers, and in many other places. Each
such use results in a "table" that maps instructions to some
piece of information. Wouldn't it be beneficial if we could just
define all instructions in one central place which collects all
the interesting information needed about them and then
generate all the tables automatically? This is precisely what
TableGen was designed to do.

On the other hand, targetTargetLowering handles all cases As a conclusion for this chapter, the LLVM has a good
of instruction nodes that cannot be lowered automatically but approach, but, for optimized code, the user has to write more
require manual intervention. These cases include: calling code than for GCC.
conventions, special instructions and operands, which cannot
be lowered automatically because of some properties and
restrictions of the architecture. One LLVM drawback in this
IV. Target Specific Optimization
field is that for a CISC architecture the code GCC cannot generate target specific optimizations, but
generation/lowering part is almost 80% hand-written. offers the possibility to configure several ones.
One important issue that the code generator needs to be Peephole optimization gathers two or more consecutive
aware of is the presence of fixed registers. In particular, there instructions into a single one. Each peephole pattern is
are often places in the instruction stream where the register described in machine description file. The peephole
allocator must arrange for a particular value to be in a optimization is called between register allocation and
particular register. This can occur due to limitations of the instruction scheduling[6]. The description contains the input
instruction set (e.g., the x86 can only do a 32-bit divide with instructions, the output instruction and the additional required
the EAX/EDX registers), or external factors like calling scratch registers. Below is an example of peephole pattern
conventions. In any case, the instruction selector should emit description:
code that copies a virtual register into or out of a physical
register when needed.
By the end of code generation, the register allocator would
coalesce the registers and delete the resultant identity moves.
MachineInstr’s are initially selected in SSA-form, and are
maintained in SSA-form until register allocation happens. For
the most part, this is trivially simple since LLVM is already in
SSA form; LLVM PHI nodes become machine code PHI
nodes, and virtual registers are only allowed to have a single
definition.
After register allocation, machine code is no longer in
SSA-form because there are no virtual registers left in the
code.
Instruction selection is arguably the most important part of Fig. 4. GCC – Peephole definition
the code generation phase. Its task is to convert a legal
selection DAG into a new DAG of target machine code. In
other words, the abstract, target-independent input has to be
matched to concrete, target-dependent output. For this purpose
LLVM uses an elaborate pattern-matching algorithm that
consists of two major steps.
The first step happens "offline", when LLVM itself is
being built, and involves the TableGen tool, which generates
the pattern-matching tables from instruction definitions.
TableGen is an important part of the LLVM eco-system, and it Fig. 5. GCC – Peephole Transformation
plays an especially central role in instruction selection, so it's
worthwhile to discuss it here more in depth.

978-1-4673-8200-7/15/$31.00 ©2015 European Union

106
Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 02,2024 at 02:04:14 UTC from IEEE Xplore. Restrictions apply.
 Define_split expression tells the compiler how to split a
complex instruction into two or more simple instructions. The
instruction split is useful in the following situations: when the
machine may have instructions which require delay slots in
between and when the output of some instructions won’t be
available for multiple cycles. This optimization has the ability
to place instructions in slots that are empty.
Fig. 6. GCC – Split Expression
The GCC offers the possibility to choose where to allocate
a local/global variable:
register int force_ra asm ("a1");
Fig. 7. GCC – Allocate a variable in a certain register
The GCC register allocation [10] is based on register
information, more precise on register classes definition, and
instruction constraints. To avoid allocation errors, the machine
description is based on the narrowest register classes for
allocatable registers.
There are multiple macros with allow the user (the one
who ports the new architecture) to configure and to improve
the default allocation. Some macros, even if they are for
configuration, require deep knowledge of both GCC compiler
implementation and architecture. One example is
MODE_BASE_REG_REG_CLASS (mode). This macro is
defined if the architecture has indexed addressing modes and
the base plus index addresses have different requirements than
other base register uses. Target hooks are another mechanism
which gives freedom to model the register allocation. The
target hook bool TARGET_CLASS_LIKELY_SPILLED_P
(reg_class_t rclass) returns true if pseudos that have been
assigned to registers of class rclass would likely be spilled
because registers of rclass are needed for spill registers.
There are many hooks and macros like those above used to
configure the allocator to be in good shape and to get the best
performance: macros to set the allocation order, to mark
special addressing modes (like preincrement, postdecrement),
define what values fit in registers, set leaf registers for leaf
functions, stack registers (if any), and registers used by calling
conventions for parameter passing.
Linear scan has been the default register allocator in
LLVM since 2004 [6]. It has worked surprisingly well for
such a simple algorithm. In fact, the simple design made it
easier to tweak the algorithm in order to make small
improvements to the generated code. More advanced register
allocation algorithms often need to build expensive data
978-1-4673-8200-7/15/$31.00 ©2015 European Union
107
Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 02,2024 at 02:04:14 UTC from IEEE Xplore. Restrictions apply.
structures, or they make assumptions about live ranges being
invariant. That makes it difficult to, say, commute a two-
address instruction on the fly, or rematerialize a constant pool
load instead of spilling it to the stack.
As the name implies, linear scan works by visiting live
ranges in a linear order. It maintains an active list of live
ranges that are live at the current point in the function, and this
is how it detects interference without computing the full
interference graph. The active list is the key to linear scan's
speed, but it is also its greatest weakness. When all physical
registers are blocked by interfering live ranges in the active
list, a live range is selected for spilling. Live ranges being
spilled without being split first cause a too complex code that
another module “rewriter” is attempting to clean up. We
would much rather split them into smaller pieces that might be
assignable, but this would require the linear scan algorithm to
backtrack. This is very expensive, and full live range splitting
isn't really feasible with linear scan.
LLVM provides several different register allocation
algorithms implemented.
Register allocation is based on the target registers
description. In LLVM registers description has 2 parts: a
descriptive one in TargetRegisterInfo.td file and a C++ one
[8].
The register information in the compiler is generated by
TableGen from the .td file and placed in
targetGenRegisterInfo.h.inc and targetGenRegisterInfo.inc.
But some of the code in targetRegisterInfo requires hand-
coding.
We should note that the automatically generated files and
classes do not provide all register-relevant functionalities and
information for a target-specific backend (there are some
virtual functions defined in the TargetRegisterInfo class not
implemented in the automatically generated class). Thus we
need to manually implement the rest of the functions to
retrieve certain register information, for
example getCalleeSavedRegs() and getFrameRegister(),
etc[9].
V. Conclusions
Retargetable compilers are a promising approach to meet
time-to-market and performance constraints. A compiler is
”retargetablȅif it can be used to generate code for different
processors by reusing significant compiler source code. This
has resulted in a paradigm shift towards a language-based
design methodology using Architecture Description Language,
exploration of architecture/compiler co-designs and automatic
compiler/simulator generation. However, whatever approach
is used, the accuracy and the performance depend on target
specific optimizations, i.e. instruction selection, register
allocation and instruction scheduling.
At this moment, we can’t talk about the best retargetable
compiler. Each user should evaluate the needs. Do we target a
small microcontroller, a risc/cisc processor or a core which in
future may be part of a multicore architecture? Another
 decision element is time constraints versus people experience
with one or another of the compilers.
References
TABLE I. GCC VS LLVM
[1] Norman Ramsey, Jack W. Davidson, “Machine descriptions to build
Compilers tools for embedded systems”, In Workshop on Languages, Compilers,
and Tools for Embedded Systems, Springer Verlag, volume 1474 of
GCC LLVM lncs, 1998 (June), pages 172–188.
Machine Declarative [2] Alfred V. Aho, Mahadevan Ganapathi, Steven W. K. Tjiang, “Code
Description RTL description language generation using tree matching and dynamic programming”,
Code Transactions on Programming Languages and Systems, 1989, 11(4),
Davison-Frasser SelectionDAG pages 491–516.
Generation
Peephole Peephole patterns in .md [3] A. V. Aho, R. Sethi, J. D. Ullman, “Compilers: Principles, Techniques,
--- and Tools”, Addison-Wesley, 1986.
Engine file
Split Engine Split patterns in .md file --- [4] Mark W., Bailey, Jack W. Davidson, “Automatic detection and
diagnosis of faults in generated code for procedure calls”, IEEE
Register 2 steps – local and global Transactions on Software Engineering, 29(11), 2003, pages 1031–1042.
Linear scan
Allocation RA [5] Christopher W. Fraser, Robert R. Henry, Todd A. Proebsting, “ BURG:
fast optimal instruction selection and tree parsing”, SIGPLAN Notices,
1992, 27(4), pages 68–76.
The GCC maintains the flexibility to create something
[6] llvm.org.
unique for each target. GCC is very mature, easy to install (at
[7] Dmitry Melnik , Andrey Belevantsev, Dmitry Plotnikov, Semun Lee, “A
least for most systems), and is the default compiler for lots of case study: optimizing GCC on ARM for performance of libevas
systems. rasterization library,” In Proceeding of GROW [2010].
From my point of view LLVM has a plus for easiness of [8] Ghassan Shobaki, Maxim Shawabkeh, Najm Abu-Rmaileh,
“Preallocation Instruction Scheduling with Register Pressure
adding new features, building and debugging, while GCC still Minimization Using a Combinatorial Optimization Approach”, ACM
has the ownership on performance for most of the targets. But Transactions on Architecture and Code Optimization, TACO, Sep. 2013.
it also should be noted that the LLVM was designed for the [9] http://www.pitt.edu/~yol26/notes/llvm3/LLVM3.html
context of multicore and multithreading programming. For [10] https://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html
example, starting from this year, LLVM has full support for [11] http://www.drdobbs.com/retargeting-the-gnu-c-compiler/184401529
OpenMP standard, based on LLVM OpenMP runtime library. [12] https://opus4.kobv.de/opus4-fau/files/1108/tricore_llvm.pdf
This feature boosts the application performance on modern
multicore architectures.

978-1-4673-8200-7/15/$31.00 ©2015 European Union

108
Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 02,2024 at 02:04:14 UTC from IEEE Xplore. Restrictions apply.