GCC Middle and Back End API Reference
ira.h File Reference
This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Data Structures

struct  target_ira
struct  ira_reg_equiv

Macros

#define this_target_ira   (&default_target_ira)
#define ira_hard_regno_allocno_class   (this_target_ira->x_ira_hard_regno_allocno_class)
#define ira_allocno_classes_num   (this_target_ira->x_ira_allocno_classes_num)
#define ira_allocno_classes   (this_target_ira->x_ira_allocno_classes)
#define ira_allocno_class_translate   (this_target_ira->x_ira_allocno_class_translate)
#define ira_pressure_classes_num   (this_target_ira->x_ira_pressure_classes_num)
#define ira_pressure_classes   (this_target_ira->x_ira_pressure_classes)
#define ira_pressure_class_translate   (this_target_ira->x_ira_pressure_class_translate)
#define ira_stack_reg_pressure_class   (this_target_ira->x_ira_stack_reg_pressure_class)
#define ira_reg_class_max_nregs   (this_target_ira->x_ira_reg_class_max_nregs)
#define ira_reg_class_min_nregs   (this_target_ira->x_ira_reg_class_min_nregs)
#define ira_memory_move_cost   (this_target_ira->x_ira_memory_move_cost)
#define ira_class_hard_regs   (this_target_ira->x_ira_class_hard_regs)
#define ira_class_hard_regs_num   (this_target_ira->x_ira_class_hard_regs_num)
#define ira_class_subset_p   (this_target_ira->x_ira_class_subset_p)
#define ira_reg_class_subset   (this_target_ira->x_ira_reg_class_subset)
#define ira_reg_classes_intersect_p   (this_target_ira->x_ira_reg_classes_intersect_p)
#define ira_class_singleton   (this_target_ira->x_ira_class_singleton)
#define ira_no_alloc_regs   (this_target_ira->x_ira_no_alloc_regs)

Functions

void ira_init_once (void)
void ira_init (void)
void ira_finish_once (void)
void ira_setup_eliminable_regset (bool)
rtx ira_eliminate_regs (rtx, enum machine_mode)
void ira_set_pseudo_classes (bool, FILE *)
void ira_implicitly_set_insn_hard_regs (HARD_REG_SET *)
void ira_expand_reg_equiv (void)
void ira_update_equiv_info_by_shuffle_insn (int, int, rtx)
void ira_sort_regnos_for_alter_reg (int *, int, unsigned int *)
void ira_mark_allocation_change (int)
void ira_mark_memory_move_deletion (int, int)
bool ira_reassign_pseudos (int *, int, HARD_REG_SET, HARD_REG_SET *, HARD_REG_SET *, bitmap)
rtx ira_reuse_stack_slot (int, unsigned int, unsigned int)
void ira_mark_new_stack_slot (rtx, int, unsigned int)
bool ira_better_spill_reload_regno_p (int *, int *, rtx, rtx, rtx)
bool ira_bad_reload_regno (int, rtx, rtx)
void ira_adjust_equiv_reg_cost (unsigned, int)

Variables

bool ira_use_lra_p
bool ira_conflicts_p
struct target_ira default_target_ira
int ira_reg_equiv_len
struct ira_reg_equivira_reg_equiv

Macro Definition Documentation

#define ira_allocno_class_translate   (this_target_ira->x_ira_allocno_class_translate)
#define ira_allocno_classes   (this_target_ira->x_ira_allocno_classes)
#define ira_allocno_classes_num   (this_target_ira->x_ira_allocno_classes_num)
#define ira_class_singleton   (this_target_ira->x_ira_class_singleton)

Referenced by setup_hard_regno_aclass().

#define ira_class_subset_p   (this_target_ira->x_ira_class_subset_p)
#define ira_hard_regno_allocno_class   (this_target_ira->x_ira_hard_regno_allocno_class)
#define ira_memory_move_cost   (this_target_ira->x_ira_memory_move_cost)
#define ira_pressure_class_translate   (this_target_ira->x_ira_pressure_class_translate)
#define ira_pressure_classes_num   (this_target_ira->x_ira_pressure_classes_num)
#define ira_reg_class_max_nregs   (this_target_ira->x_ira_reg_class_max_nregs)
#define ira_reg_class_min_nregs   (this_target_ira->x_ira_reg_class_min_nregs)
#define ira_reg_class_subset   (this_target_ira->x_ira_reg_class_subset)
#define ira_reg_classes_intersect_p   (this_target_ira->x_ira_reg_classes_intersect_p)
#define ira_stack_reg_pressure_class   (this_target_ira->x_ira_stack_reg_pressure_class)

Referenced by ira_debug_disposition().

#define this_target_ira   (&default_target_ira)

Function Documentation

void ira_adjust_equiv_reg_cost ( unsigned  ,
int   
)
bool ira_bad_reload_regno ( int  ,
rtx  ,
rtx   
)
bool ira_better_spill_reload_regno_p ( int *  regnos,
int *  other_regnos,
rtx  in,
rtx  out,
rtx  insn 
)

Return TRUE if spilling pseudo-registers whose numbers are in array REGNOS is better than spilling pseudo-registers with numbers in OTHER_REGNOS for reload with given IN and OUT for INSN. The function used by the reload pass to make better register spilling decisions.

rtx ira_eliminate_regs ( rtx  ,
enum  machine_mode 
)
void ira_expand_reg_equiv ( void  )

Expand ira_reg_equiv if necessary.

void ira_finish_once ( void  )

Function called once at the end of compiler work.

Referenced by lang_dependent_init_target().

void ira_implicitly_set_insn_hard_regs ( HARD_REG_SET )
void ira_init ( void  )

This is called every time when register related information is changed.

References recog_data_d::alternative_enabled_p, and recog_data.

void ira_init_once ( void  )

This is called once during compiler work. It sets up different arrays whose values don't depend on the compiled function.

References gen_rtx_REG(), and ira_prohibited_mode_move_regs_initialized_p.

void ira_mark_allocation_change ( int  )
void ira_mark_memory_move_deletion ( int  ,
int   
)
void ira_mark_new_stack_slot ( rtx  ,
int  ,
unsigned  int 
)
bool ira_reassign_pseudos ( int *  spilled_pseudo_regs,
int  num,
HARD_REG_SET  bad_spill_regs,
HARD_REG_SET pseudo_forbidden_regs,
HARD_REG_SET pseudo_previous_regs,
bitmap  spilled 
)

Try to allocate hard registers to SPILLED_PSEUDO_REGS (there are NUM of them) or spilled pseudos conflicting with pseudos in SPILLED_PSEUDO_REGS. Return TRUE and update SPILLED, if the allocation has been changed. The function doesn't use BAD_SPILL_REGS and hard registers in PSEUDO_FORBIDDEN_REGS and PSEUDO_PREVIOUS_REGS for the corresponding pseudos. The function is called by the reload pass at the end of each reload iteration.

 Add pseudos which conflict with pseudos already in
 SPILLED_PSEUDO_REGS to SPILLED_PSEUDO_REGS.  This is preferable
 to allocating in two steps as some of the conflicts might have
 a higher priority than the pseudos passed in SPILLED_PSEUDO_REGS.   
                 ?!? This seems wrong.   
 Try to assign hard registers to pseudos from
 SPILLED_PSEUDO_REGS.   

References ALLOCNO_CLASS, ALLOCNO_CLASS_COST, ALLOCNO_EXCESS_PRESSURE_POINTS_NUM, ALLOCNO_MEMORY_COST, ALLOCNO_MODE, ALLOCNO_NUM_OBJECTS, BLOCK_FOR_INSN, call_used_reg_set, find_regno_note(), hard_regno_nregs, ira_assert, ira_memory_move_cost, ira_regno_allocno_map, NULL_RTX, REG_FREQ_FROM_BB, REG_N_REFS(), REG_P, reg_renumber, REGNO, and TEST_HARD_REG_BIT.

rtx ira_reuse_stack_slot ( int  regno,
unsigned int  inherent_size,
unsigned int  total_size 
)

The function is called by reload and returns already allocated stack slot (if any) for REGNO with given INHERENT_SIZE and TOTAL_SIZE. In the case of failure to find a slot which can be used for REGNO, the function returns NULL.

It means that the pseudo was spilled in the reload pass, try to reuse a slot.

References initiate_cost_update(), ira_allocate(), ira_allocate_bitmap(), and ira_allocnos_num.

void ira_set_pseudo_classes ( bool  ,
FILE *   
)
void ira_setup_eliminable_regset ( bool  )
void ira_sort_regnos_for_alter_reg ( int *  pseudo_regnos,
int  n,
unsigned int *  reg_max_ref_width 
)

Sort pseudo-register numbers in array PSEUDO_REGNOS of length N for subsequent assigning stack slots to them in the reload pass. To do this we coalesce spilled allocnos first to decrease the number of memory-memory move insns. This function is called by the reload.

 Set up allocnos can be coalesced.   
 Initialize coalesce data for allocnos.   
 Sort regnos according frequencies of the corresponding coalesced
 allocno sets.   
 Collect allocnos representing the spilled coalesced allocno
 sets.   
 Assign stack slot numbers to spilled allocno sets, use smaller
 numbers for most frequently used coalesced allocnos.  -1 is
 reserved for dynamic search of stack slots for pseudos spilled by
 the reload.   
 Sort regnos according the slot numbers.   
void ira_update_equiv_info_by_shuffle_insn ( int  ,
int  ,
rtx   
)

Variable Documentation

struct target_ira default_target_ira

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.

bool ira_conflicts_p

True if we have allocno conflicts. It is false for non-optimized mode or when the conflict table is too big.

Referenced by maybe_fix_stack_asms(), print_conflicts(), and setup_reg_equiv().

Info about equiv. info for each register.

int ira_reg_equiv_len

The length of the following array.

bool ira_use_lra_p

Communication between the Integrated Register Allocator (IRA) and the rest of the compiler. 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/. True when we use LRA instead of reload pass for the current function.

True when we use LRA instead of reload pass for the current function.