Live Interval Analysis identifies the ranges where a variable is live. -It's used by the register allocator pass to determine -if two or more virtual registers which require the same register are live at -the same point in the program (conflict). When this situation occurs, one -virtual register must be spilt.
+Live Intervals are the ranges (intervals) where a variable is live. +They are used by some register allocator passes to +determine if two or more virtual registers which require the same register are +live at the same point in the program (conflict). When this situation occurs, +one virtual register must be spilled.
The first step to determining the live intervals of variables is to +
The first step in determining the live intervals of variables is to calculate the set of registers that are immediately dead after the -instruction (i.e., the instruction calculates the value, but it is never -used) and the set of registers that are used by the instruction, but are -never used after the instruction (i.e., they are killed). Live variable -information is computed for each virtual and register -allocatable physical register in the function. LLVM assumes that -physical registers are only live within a single basic block. This allows -it to do a single, local analysis to resolve physical register lifetimes in -each basic block. If a physical register is not register allocatable (e.g., +instruction (i.e., the instruction calculates the value, but it is +never used) and the set of registers that are used by the instruction, +but are never used after the instruction (i.e., they are killed). Live +variable information is computed for each virtual and +register allocatable physical register in the function. This +is done in a very efficient manner because it uses SSA to sparsely +computer lifetime information for virtual registers (which are in SSA +form) and only has to track physical registers within a block. Before +register allocation, LLVM can assume that physical registers are only +live within a single basic block. This allows it to do a single, +local analysis to resolve physical register lifetimes within each +basic block. If a physical register is not register allocatable (e.g., a stack pointer or condition codes), it is not tracked.
Physical registers may be live in to or out of a function. Live in values -are typically arguments in register. Live out values are typically return +are typically arguments in registers. Live out values are typically return values in registers. Live in values are marked as such, and are given a dummy "defining" instruction during live interval analysis. If the last basic block -of a function is a return, then it's marked as using all live-out +of a function is a return, then it's marked as using all live out values in the function.
PHI nodes need to be handled specially, because the calculation of the live variable information from a depth first traversal of the CFG of -the function won't guarantee that a virtual register is defined before it's -used. When a PHI node is encounted, only the definition is -handled, because the uses will be handled in other basic blocks.
+the function won't guarantee that a virtual register used by the PHI +node is defined before it's used. When a PHI node is encounted, only +the definition is handled, because the uses will be handled in other basic +blocks.For each PHI node of the current basic block, we simulate an assignment at the end of the current basic block and traverse the successor @@ -1215,132 +1221,16 @@ defining instruction is encountered.
To Be Written
+ - - /// VarInfo - This represents the regions where a virtual register is live in - /// the program. We represent this with three different pieces of - /// information: the instruction that uniquely defines the value, the set of - /// blocks the instruction is live into and live out of, and the set of - /// non-phi instructions that are the last users of the value. - /// - /// In the common case where a value is defined and killed in the same block, - /// DefInst is the defining inst, there is one killing instruction, and - /// AliveBlocks is empty. - /// - /// Otherwise, the value is live out of the block. If the value is live - /// across any blocks, these blocks are listed in AliveBlocks. Blocks where - /// the liveness range ends are not included in AliveBlocks, instead being - /// captured by the Kills set. In these blocks, the value is live into the - /// block (unless the value is defined and killed in the same block) and lives - /// until the specified instruction. Note that there cannot ever be a value - /// whose Kills set contains two instructions from the same basic block. - /// - /// PHI nodes complicate things a bit. If a PHI node is the last user of a - /// value in one of its predecessor blocks, it is not listed in the kills set, - /// but does include the predecessor block in the AliveBlocks set (unless that - /// block also defines the value). This leads to the (perfectly sensical) - /// situation where a value is defined in a block, and the last use is a phi - /// node in the successor. In this case, DefInst will be the defining - /// instruction, AliveBlocks is empty (the value is not live across any - /// blocks) and Kills is empty (phi nodes are not included). This is sensical - /// because the value must be live to the end of the block, but is not live in - /// any successor blocks. - - --> +