@verbatim
Integrated Register Allocator (IRA) entry point. Copyright (C) 2006-2013 Free Software Foundation, Inc. Contributed by Vladimir Makarov vmaka.nosp@m.rov@.nosp@m.redha.nosp@m.t.co.nosp@m.m.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/.
The integrated register allocator (IRA) is a
regional register allocator performing graph coloring on a top-down
traversal of nested regions. Graph coloring in a region is based
on Chaitin-Briggs algorithm. It is called integrated because
register coalescing, register live range splitting, and choosing a
better hard register are done on-the-fly during coloring. Register
coalescing and choosing a cheaper hard register is done by hard
register preferencing during hard register assigning. The live
range splitting is a byproduct of the regional register allocation.
Major IRA notions are:
o *Region* is a part of CFG where graph coloring based on
Chaitin-Briggs algorithm is done. IRA can work on any set of
nested CFG regions forming a tree. Currently the regions are
the entire function for the root region and natural loops for
the other regions. Therefore data structure representing a
region is called loop_tree_node.
o *Allocno class* is a register class used for allocation of
given allocno. It means that only hard register of given
register class can be assigned to given allocno. In reality,
even smaller subset of (*profitable*) hard registers can be
assigned. In rare cases, the subset can be even smaller
because our modification of Chaitin-Briggs algorithm requires
that sets of hard registers can be assigned to allocnos forms a
forest, i.e. the sets can be ordered in a way where any
previous set is not intersected with given set or is a superset
of given set.
o *Pressure class* is a register class belonging to a set of
register classes containing all of the hard-registers available
for register allocation. The set of all pressure classes for a
target is defined in the corresponding machine-description file
according some criteria. Register pressure is calculated only
for pressure classes and it affects some IRA decisions as
forming allocation regions.
o *Allocno* represents the live range of a pseudo-register in a
region. Besides the obvious attributes like the corresponding
pseudo-register number, allocno class, conflicting allocnos and
conflicting hard-registers, there are a few allocno attributes
which are important for understanding the allocation algorithm:
- *Live ranges*. This is a list of ranges of *program points*
where the allocno lives. Program points represent places
where a pseudo can be born or become dead (there are
approximately two times more program points than the insns)
and they are represented by integers starting with 0. The
live ranges are used to find conflicts between allocnos.
They also play very important role for the transformation of
the IRA internal representation of several regions into a one
region representation. The later is used during the reload
pass work because each allocno represents all of the
corresponding pseudo-registers.
- *Hard-register costs*. This is a vector of size equal to the
number of available hard-registers of the allocno class. The
cost of a callee-clobbered hard-register for an allocno is
increased by the cost of save/restore code around the calls
through the given allocno's life. If the allocno is a move
instruction operand and another operand is a hard-register of
the allocno class, the cost of the hard-register is decreased
by the move cost.
When an allocno is assigned, the hard-register with minimal
full cost is used. Initially, a hard-register's full cost is
the corresponding value from the hard-register's cost vector.
If the allocno is connected by a *copy* (see below) to
another allocno which has just received a hard-register, the
cost of the hard-register is decreased. Before choosing a
hard-register for an allocno, the allocno's current costs of
the hard-registers are modified by the conflict hard-register
costs of all of the conflicting allocnos which are not
assigned yet.
- *Conflict hard-register costs*. This is a vector of the same
size as the hard-register costs vector. To permit an
unassigned allocno to get a better hard-register, IRA uses
this vector to calculate the final full cost of the
available hard-registers. Conflict hard-register costs of an
unassigned allocno are also changed with a change of the
hard-register cost of the allocno when a copy involving the
allocno is processed as described above. This is done to
show other unassigned allocnos that a given allocno prefers
some hard-registers in order to remove the move instruction
corresponding to the copy.
o *Cap*. If a pseudo-register does not live in a region but
lives in a nested region, IRA creates a special allocno called
a cap in the outer region. A region cap is also created for a
subregion cap.
o *Copy*. Allocnos can be connected by copies. Copies are used
to modify hard-register costs for allocnos during coloring.
Such modifications reflects a preference to use the same
hard-register for the allocnos connected by copies. Usually
copies are created for move insns (in this case it results in
register coalescing). But IRA also creates copies for operands
of an insn which should be assigned to the same hard-register
due to constraints in the machine description (it usually
results in removing a move generated in reload to satisfy
the constraints) and copies referring to the allocno which is
the output operand of an instruction and the allocno which is
an input operand dying in the instruction (creation of such
copies results in less register shuffling). IRA *does not*
create copies between the same register allocnos from different
regions because we use another technique for propagating
hard-register preference on the borders of regions.
Allocnos (including caps) for the upper region in the region tree
*accumulate* information important for coloring from allocnos with
the same pseudo-register from nested regions. This includes
hard-register and memory costs, conflicts with hard-registers,
allocno conflicts, allocno copies and more. *Thus, attributes for
allocnos in a region have the same values as if the region had no
subregions*. It means that attributes for allocnos in the
outermost region corresponding to the function have the same values
as though the allocation used only one region which is the entire
function. It also means that we can look at IRA work as if the
first IRA did allocation for all function then it improved the
allocation for loops then their subloops and so on.
IRA major passes are:
o Building IRA internal representation which consists of the
following subpasses:
* First, IRA builds regions and creates allocnos (file
ira-build.c) and initializes most of their attributes.
* Then IRA finds an allocno class for each allocno and
calculates its initial (non-accumulated) cost of memory and
each hard-register of its allocno class (file ira-cost.c).
* IRA creates live ranges of each allocno, calulates register
pressure for each pressure class in each region, sets up
conflict hard registers for each allocno and info about calls
the allocno lives through (file ira-lives.c).
* IRA removes low register pressure loops from the regions
mostly to speed IRA up (file ira-build.c).
* IRA propagates accumulated allocno info from lower region
allocnos to corresponding upper region allocnos (file
ira-build.c).
* IRA creates all caps (file ira-build.c).
* Having live-ranges of allocnos and their classes, IRA creates
conflicting allocnos for each allocno. Conflicting allocnos
are stored as a bit vector or array of pointers to the
conflicting allocnos whatever is more profitable (file
ira-conflicts.c). At this point IRA creates allocno copies.
o Coloring. Now IRA has all necessary info to start graph coloring
process. It is done in each region on top-down traverse of the
region tree (file ira-color.c). There are following subpasses:
* Finding profitable hard registers of corresponding allocno
class for each allocno. For example, only callee-saved hard
registers are frequently profitable for allocnos living
through colors. If the profitable hard register set of
allocno does not form a tree based on subset relation, we use
some approximation to form the tree. This approximation is
used to figure out trivial colorability of allocnos. The
approximation is a pretty rare case.
* Putting allocnos onto the coloring stack. IRA uses Briggs
optimistic coloring which is a major improvement over
Chaitin's coloring. Therefore IRA does not spill allocnos at
this point. There is some freedom in the order of putting
allocnos on the stack which can affect the final result of
the allocation. IRA uses some heuristics to improve the
order.
We also use a modification of Chaitin-Briggs algorithm which
works for intersected register classes of allocnos. To
figure out trivial colorability of allocnos, the mentioned
above tree of hard register sets is used. To get an idea how
the algorithm works in i386 example, let us consider an
allocno to which any general hard register can be assigned.
If the allocno conflicts with eight allocnos to which only
EAX register can be assigned, given allocno is still
trivially colorable because all conflicting allocnos might be
assigned only to EAX and all other general hard registers are
still free.
To get an idea of the used trivial colorability criterion, it
is also useful to read article "Graph-Coloring Register
Allocation for Irregular Architectures" by Michael D. Smith
and Glen Holloway. Major difference between the article
approach and approach used in IRA is that Smith's approach
takes register classes only from machine description and IRA
calculate register classes from intermediate code too
(e.g. an explicit usage of hard registers in RTL code for
parameter passing can result in creation of additional
register classes which contain or exclude the hard
registers). That makes IRA approach useful for improving
coloring even for architectures with regular register files
and in fact some benchmarking shows the improvement for
regular class architectures is even bigger than for irregular
ones. Another difference is that Smith's approach chooses
intersection of classes of all insn operands in which a given
pseudo occurs. IRA can use bigger classes if it is still
more profitable than memory usage.
* Popping the allocnos from the stack and assigning them hard
registers. If IRA can not assign a hard register to an
allocno and the allocno is coalesced, IRA undoes the
coalescing and puts the uncoalesced allocnos onto the stack in
the hope that some such allocnos will get a hard register
separately. If IRA fails to assign hard register or memory
is more profitable for it, IRA spills the allocno. IRA
assigns the allocno the hard-register with minimal full
allocation cost which reflects the cost of usage of the
hard-register for the allocno and cost of usage of the
hard-register for allocnos conflicting with given allocno.
* Chaitin-Briggs coloring assigns as many pseudos as possible
to hard registers. After coloringh we try to improve
allocation with cost point of view. We improve the
allocation by spilling some allocnos and assigning the freed
hard registers to other allocnos if it decreases the overall
allocation cost.
* After allono assigning in the region, IRA modifies the hard
register and memory costs for the corresponding allocnos in
the subregions to reflect the cost of possible loads, stores,
or moves on the border of the region and its subregions.
When default regional allocation algorithm is used
(-fira-algorithm=mixed), IRA just propagates the assignment
for allocnos if the register pressure in the region for the
corresponding pressure class is less than number of available
hard registers for given pressure class.
o Spill/restore code moving. When IRA performs an allocation
by traversing regions in top-down order, it does not know what
happens below in the region tree. Therefore, sometimes IRA
misses opportunities to perform a better allocation. A simple
optimization tries to improve allocation in a region having
subregions and containing in another region. If the
corresponding allocnos in the subregion are spilled, it spills
the region allocno if it is profitable. The optimization
implements a simple iterative algorithm performing profitable
transformations while they are still possible. It is fast in
practice, so there is no real need for a better time complexity
algorithm.
o Code change. After coloring, two allocnos representing the
same pseudo-register outside and inside a region respectively
may be assigned to different locations (hard-registers or
memory). In this case IRA creates and uses a new
pseudo-register inside the region and adds code to move allocno
values on the region's borders. This is done during top-down
traversal of the regions (file ira-emit.c). In some
complicated cases IRA can create a new allocno to move allocno
values (e.g. when a swap of values stored in two hard-registers
is needed). At this stage, the new allocno is marked as
spilled. IRA still creates the pseudo-register and the moves
on the region borders even when both allocnos were assigned to
the same hard-register. If the reload pass spills a
pseudo-register for some reason, the effect will be smaller
because another allocno will still be in the hard-register. In
most cases, this is better then spilling both allocnos. If
reload does not change the allocation for the two
pseudo-registers, the trivial move will be removed by
post-reload optimizations. IRA does not generate moves for
allocnos assigned to the same hard register when the default
regional allocation algorithm is used and the register pressure
in the region for the corresponding pressure class is less than
number of available hard registers for given pressure class.
IRA also does some optimizations to remove redundant stores and
to reduce code duplication on the region borders.
o Flattening internal representation. After changing code, IRA
transforms its internal representation for several regions into
one region representation (file ira-build.c). This process is
called IR flattening. Such process is more complicated than IR
rebuilding would be, but is much faster.
o After IR flattening, IRA tries to assign hard registers to all
spilled allocnos. This is impelemented by a simple and fast
priority coloring algorithm (see function
ira_reassign_conflict_allocnos::ira-color.c). Here new allocnos
created during the code change pass can be assigned to hard
registers.
o At the end IRA calls the reload pass. The reload pass
communicates with IRA through several functions in file
ira-color.c to improve its decisions in
* sharing stack slots for the spilled pseudos based on IRA info
about pseudo-register conflicts.
* reassigning hard-registers to all spilled pseudos at the end
of each reload iteration.
* choosing a better hard-register to spill based on IRA info
about pseudo-register live ranges and the register pressure
in places where the pseudo-register lives.
IRA uses a lot of data representing the target processors. These
data are initilized in file ira.c.
If function has no loops (or the loops are ignored when
-fira-algorithm=CB is used), we have classic Chaitin-Briggs
coloring (only instead of separate pass of coalescing, we use hard
register preferencing). In such case, IRA works much faster
because many things are not made (like IR flattening, the
spill/restore optimization, and the code change).
Literature is worth to read for better understanding the code:
o Preston Briggs, Keith D. Cooper, Linda Torczon. Improvements to
Graph Coloring Register Allocation.
o David Callahan, Brian Koblenz. Register allocation via
hierarchical graph coloring.
o Keith Cooper, Anshuman Dasgupta, Jason Eckhardt. Revisiting Graph
Coloring Register Allocation: A Study of the Chaitin-Briggs and
Callahan-Koblenz Algorithms.
o Guei-Yuan Lueh, Thomas Gross, and Ali-Reza Adl-Tabatabai. Global
Register Allocation Based on Graph Fusion.
o Michael D. Smith and Glenn Holloway. Graph-Coloring Register
Allocation for Irregular Architectures
o Vladimir Makarov. The Integrated Register Allocator for GCC.
o Vladimir Makarov. The top-down register allocator for irregular
register file architectures.
1.8.1.1