User:Grophi/sandbox

In compiler optimization, register allocation is the process of assigning a large number of target program variables onto a small number of CPU registers.

Register allocation can happen over a basic block (local register allocation), over a whole function/procedure (global register allocation), or across function boundaries traversed via call-graph (interprocedural register allocation). When done per function/procedure the calling convention may require insertion of save/restore around each call-site.

Principle
In many programming languages, the programmer may use any number of variables. The computer can quickly read and write registers in the CPU, so the computer program runs faster when more variables can be in the CPU's registers. Also, sometimes code accessing registers is more compact, so the code is smaller, and can be fetched faster if it uses registers rather than memory. However, the number of registers is limited in most CPUs. Therefore, when the compiler is translating code to machine-language, it must decide how to allocate variables to the limited number of registers in the CPU. ,



Not all variables are in use (or "live") at the same time, so, over the lifetime of a program, a given register may be used to hold different variables. However, two variables in use at the same time cannot be assigned to the same register without corrupting one of the variables. If there are not enough registers to hold all the variables, some variables may be moved to and from RAM. This process is called "spilling" the registers. Over the lifetime of a program, a variable can be both spilled and stored in registers: this variable is then considered as "split". Accessing RAM is significantly slower than accessing registers and so a compiled program runs slower. Therefore, an optimizing compiler aims to assign as many variables to registers as possible. A high "Register pressure" is a technical term that means that more spills and reloads are needed; it is defined by Braun et al. as "the number of simultaneously live variables at an instruction".

In addition, some computer designs cache frequently-accessed registers. So, programs can be further optimized by assigning the same register to a source and destination of a  instruction whenever possible. This is especially important if the compiler is using an intermediate representation such as static single-assignment form (SSA). In particular, when SSA is not fully optimized it can artificially generate additional  instructions.

Challenges of register allocation
Register allocation consists therefore in choosing where to store the variables at runtime, i.e. in registers or outside registers. If the variable is to be stored in registers, then the allocator needs to determine in which register(s) this variable will be stored. Eventually, another challenge is to determine the duration for which a variable should stay at the same location.

A register allocator, disregarding the chosen allocation strategy, can rely on a set of core actions to address these challenges. These actions can be gathered in three different categories: Mostly, a lot of register allocation approaches try to specifically optimize one or the other category of actions.
 * Move insertion: This action consists in increasing the amount of move instructions between registers, i.e. make a variable live in different registers during its lifetime, instead of one. This occurs in the split live range approach.
 * Spilling: This action consists in storing a variable into memory instead of registers
 * Assignment: This action consists in assigning a register to a variable.
 * Coalescing: This action consists in limiting the number of moves between registers, thus limiting the total amount of instructions. For instance, by identifying a variable live across different methods, and storing it into one register during its whole lifetime.

Common problems raised in register allocation

 * Aliasing: In some architectures, when an assignment to one register can affect the value of another. For example the x86 architecture has four general purpose 32-bit registers that can also be used as 16-bit or 8-bits registers.


 * Pre-coloring: This problem is an act to force some variables to be assigned to particular registers. For example, in PowerPC architecture parameters are commonly passed in R3-R10 and the return value is passed in R3.


 * NP-Problem: Chaitin et al. showed that their register allocation algorithm is an NP-complete problem. Their work is based on graph coloring problem, where each node represents a variable and color represents the amount of machine registers. That graph can be arbitrary, thereby proving the NP-completeness of the problem.

Register allocation techniques
Register allocation can happen over a basic block of code: it is said to be "local", and was first mentioned by Horwitz et al. . As basic blocks does not contain branches, the allocation process is thought to be fast, because the management of control flow graph merge points in register allocation reveals itself a time-consuming operation. However, this approach is thought not to produce as optimized code as the "global" approach, which operates over the whole compilation unit (a method or procedure for instance).

Graph-coloring allocation
Graph-coloring allocation is the predominant approach to solve register allocation. It was first proposed by Chaitin and al., In this approach, nodes in the graph represent live ranges (variables, temporaries, virtual/symbolic registers) that are candidates for register allocation. Edges connect live ranges that interfere, i.e., live ranges that are simultaneously live at at least one program point. Register allocation then reduces to the graph coloring problem in which colors (registers) are assigned to the nodes such that two nodes connected by an edge do not receive the same color.

Using liveness analysis, an interference graph can be built. The interference graph which is an undirected graph where the nodes are the program's variables is used to model which variables cannot be allocated to the same register.

Principle
The main phases in a Chaitin-style graph-coloring register allocator are:
 * 1) Renumber: discover live range information in the source program.
 * 2) Build: build the interference graph.
 * 3) Coalesce: merge the live ranges of non-interfering variables related by copy instructions.
 * 4) Spill cost: compute the spill cost of each variable. This assesses the impact of mapping a variable to memory on the speed of the final program.
 * 5) Simplify: construct an ordering of the nodes in the inferences graph
 * 6) Spill Code: insert spill instructions, i.e loads and stores to commute values between registers and memory.
 * 7) Select: assign a register to each variable.

Drawbacks and further improvements
The graph-coloring allocation has three major drawbacks. First, it relies on graph-coloring, which is an NP-complete problem, to decide which variables are spilled. Finding a minimal coloring graph is indeed a NP-complete problem. Second, unless live-range splitting is used, evicted variables are spilled everywhere: store (resp. load) instructions are inserted as early (resp. late) as possible, i.e., just after (resp. before) variable definitions (resp. uses). Third, a variable that is not spilled is kept in the same register throughout its whole lifetime. Furthermore, when a single register name may appear in multiple register classes, where a class is a set of register names that are interchangeable in a particular role. Second, multiple register names may be aliases for a single hardware register Finally, graph coloring is an aggressive technique for allocating registers, but is computationally expensive due to its use of the interference graph, which can have a worst-case size that is quadratic in the number of live ranges. The traditional formulation of graph-coloring register allocation implicitly assumes a single bank of non-overlapping general-purpose registers and does not handle irregular architectural features like overlapping registers pairs, special purpose registers and multiple register banks

One later improvement of Chaitin-style graph-coloring approach was found by Briggs et al.: it is called conservative coalescing. This improvement adds a criteria to decide when two live ranges can be merged. Mainly, in addition to the non-interfering requirements, two variables can only be coalesced if their merging will not cause further spilling. Briggs et al. introduces a second improvement to Chaitin's works which is biased coloring. Biased coloring tries to assign the same color in the graph-coloring to live range that are copy related.

Linear Scan
Linear scan is another global register allocation approach. It was first proposed by Poletto et. al in 1999. In this approach, the code is not turned into a graph. Instead, all the variables are linearly scanned to determine their live range, represented as an interval. Once the live ranges of all variables have been figured out, the intervals are  traversed chronologically. Although this traversal could help identifying variables whose live ranges interfere, no interference graph is being built and the variables are allocated in a greedy way.

The motivation for this approach is speed; not in terms of execution time of the generated code, but in terms of time spent in code generation. Typically, the standard graph coloring approaches produces quality code, but has a significant overhead, the used graph coloring algorithm having a quadratic cost. Due to this feature, linear scan is the approach currently in use in several JIT compilers, like the Hotspot compiler, V8 and Jikes RVM.

Pseudo code
This describes the algorithm as first proposed by Poletto et al.  LinearScanRegisterAllocation active ← {} foreach live interval i, in order of increasing start point ExpireOldIntervals(i) if length(active)=R then SpillAtInterval(i) else register[i] ← a register removed from pool of free registers add i to active, sorted by increasing end point

ExpireOldIntervals(i) foreach interval j in active, in order of increasing end point if endpoint[j] ≥ startpoint[i] then return remove j from active add register[j] to pool of free registers

'''SpillAtInterval(i) spill ← last interval in active if endpoint[spill] > endpoint[i] then register[i] ← register[spill] location[spill] ← new stack location remove spill from active add i to active, sorted by increasing end point else location[i] ← new stack location

Drawbacks and further improvements
However, the linear scan presents two major drawbacks. First, due to its greedy aspect, it does not take lifetime holes into account, i.e. "ranges where the value of the variable is not needed". Besides, a spilled variable will stay spilled for its entire lifetime.

Lots of other research works followed up on the Poletto's linear scan algorithm. Traub et al., for instance, proposed an algorithm called second-chance binpacking aiming at generating code of better quality. Indeed, in this approach, spilled variables get the opportunity to be stored later in a register by using a different heuristic from the one used in the standard linear scan algorithm. Indeed, instead of using live intervals, the algorithm relies on live ranges, meaning that if a range needs to be spilled, it is not necessary to spill all the other ranges corresponding to this variable.

Linear scan allocation was also adapted to take advantage from the SSA form: the properties of this intermediate representation are used to make the allocation algorithm simpler. First, the time spent in data flow graph analysis, aimed at building the lifetime intervals, is reduced, namely because variables are unique. It consequently produces shorter live intervals, because each new assignment corresponds to a new live interval

Rematerialization
The problem of optimal register allocation is NP-complete. As a consequence, compilers employ heuristic techniques to approximate its solution.

Chaitin et al. discuss several ideas for improving the quality of spill code. They point out that certain values can be recomputed in a single instruction and that required operand will always be available for the computation. They call these exceptional values "never-killed" and note that such values should be recalculated instead of being spilled and reloaded. They further note that an uncoalesced copy of a never-killed value can be eliminated by recomputing it directly into the desired register.

These techniques are termed rematerialization. In practice, opportunities for rematerialization include:
 * immediate loads of integer constants and, on some machines, floating-point constants,
 * computing a constant offset from the frame pointer or the static data area, and
 * loading non-local frame pointers from a display.

Briggs and Al extends Chaitin's work to take advantage of rematerialization opportunities for complex, multi-valued live ranges. They found that each value needs to be tagged with enough information to allow the allocator to handle it correctly. Briggs's approach is the following: first, split each live range into its component values, then propagate rematerialization tags to each value, and form new live ranges from connected values having identical tags.

Coalescing
In the context of register allocation, coalescing is the act of merging variable-to-variable move operations by allocating those two variables to the same location. The coalescing operation takes place after the interference graph is built. Once two nodes have been coalesced, they must get the same color and be allocated to the same register, once the copy operation becomes unnecessary.

Doing coalescing might have both positive and negative impacts on the colorability of the interference graph. For example, one negative impact that coalescing could have on graph inference colorability is when two nodes are coalesced, as the result node will have a union of the edges of those being coalesced. A positive impact of coalescing on inference graph colorability is, for example, when a node interferes with both nodes being coalesced, the degree of the node is reduced by one which leads to improving the overall colorability of the interference graph.

There are several coalescing heuristics available :


 * Aggressive coalescing: it was first introduced by Chaitin original register allocator. This heuristic aims at coalescing any non-interfering, copy-related nodes. From the perspective of copy elimination, this heuristic has the best results . On the other hand, aggressive coalescing cloud impacts the inference graph colorability..
 * Conservative Coalescing: it mainly uses the same heuristic as aggressive coalescing but it merges moves if, and only if, it does not compromise the colorability of the interference graph.
 * Iterated coalescing: it removes one particular move at the time, while keeping the colorability of the graph.
 * Optimistic coalescing: it is based on aggressive coalescing, but if the inference graph colorability is compromised, then it gives up as few moves as possible.

Hybrid allocation
Some other register allocation approaches do not limit to one technique to optimize the register use. Cavazos et.al, for instance, proposed a solution where it is possible to use both the linear scan and the graph coloring algorithms. In this approach, the choice between one or the other solution is determined dynamically: first, a machine learning algorithm is used "offline", that is to say not at runtime, to build an heuristic function that determine which allocation algorithm need to be used. The heuristic function is then used at runtime; in light of the code behavior, the allocator can then chose between one of the two available algorithms.

Trace register allocation is a recent approach developed by Eisl et al.,. This technique handles the allocation locally: it relies on dynamic profiling data to determine which branches will be the most frequently used in a given control flow graph. It then infers a set of "traces" (i.e. code segments) in which the merge point is ignored in favor of the most used branch. Each trace is then independently processed by the allocator. This approach can be considered as hybrid because it is possible to use different register allocation algorithms between the different traces.

Split allocation
Split allocation is another register allocation technique that combines different approaches, usually considered as opposite. For instance, the hybrid allocation technique can be considered as split because the first heuristic building stage is performed offline, and the heuristic use is performed online. In the same fashion, B. Diouf et al. proposed an allocation technique relying both on offline and online behaviors, namely static and dynamic compilation. , . During the offline stage, a spill set is gathered and annotated. Register allocation is performed afterwards during the online stage, based on the data collected in the offline phase. In 2007, Bouchez et al suggested as well to split the register allocation in different stages, having one stage dedicated to spilling, and one dedicated to coloring and coalescing.

Comparison between the different techniques
Several metrics have been used to assess the performance of one register allocation technique against the other. Register allocation has typically to deal with a trade-off between code quality, i.e. code that executes quickly, and analysis overhead, i.e. the time spent determining analyzing the source code to generate code with optimized register allocation. From this perspective, execution time of the generated code and time spent in liveness analysis are relevant metrics to compare the different techniques.

Once relevant metrics have been chosen, the code on which the metrics will be applied should be available and relevant to the problem, either by reflecting the behavior of real-world application, or by being relevant to the particular problem the algorithm wants to address. The more recent articles about register allocation uses especially the Dacapo benchmark suite.