compiler

Unnamed Compiled Systems Language Project
git clone http://frotz.net/git/compiler.git
Log | Files | Refs

llvm-live-ranges-of-physical-registers--lattner-2006.txt (3468B)


      1 
      2 LLVM has 3 register types:
      3 - virtual (normal ssa regs)
      4 - physical (short live span, only w/in basic blocks)
      5 - physical untracked (SP, FP, etc, special purpose)
      6 
      7 
      8 https://lists.llvm.org/pipermail/llvm-dev/2006-June/006084.html
      9 
     10 [LLVMdev] Live ranges of physical registers
     11 Chris Lattner sabre at nondot.org
     12 Fri Jun 2 10:26:09 PDT 2006
     13 
     14 On Thu, 1 Jun 2006, Fernando Magno Quintao Pereira wrote:
     15 >    I am coding a liveness analysis algorithm, and I found this comment
     16 > on LiveVariables.cpp:
     17 >
     18 > Line 00195 - http://llvm.org/doxygen/LiveVariables_8cpp-source.html :
     19 >
     20 >  // PhysRegInfo - Keep track of which instruction was the last use of a
     21 >  // physical register.  This is a purely local property, because all
     22 > physical
     23 >  // register references as presumed dead across basic blocks.
     24 >
     25 > Indeed, I am using the X86 architecture, and I could not find
     26 > general purpose registers such as EAX, EBX, etc, alive in between basic
     27 > blocks in the control flow graphs generated by LLVM.
     28 
     29 Yup!
     30 
     31 > (some specific registers, such as the stack pointer, will be, of
     32 > course, alive). Could someone tell me a little bit about this?
     33 > Is this property true due to the way LLVM generates code?
     34 > Can I assume that registers available for register allocation will not
     35 > be alive in between basic blocks?
     36 
     37 Before register allocation, there are three types of registers:
     38 
     39 1. Virtual registers.  These are in SSA form, and follow all the normal
     40     SSA properties.  These can be live across blocks.
     41 2. Unallocatable physical registers (e.g. ESP).  These can be live
     42     anywhere and can be used/modified in ways the register allocator is not
     43     required to understand.
     44 3. Allocatable physregs (e.g. EAX).  These are *required* to only be live
     45     within a machine basic block.  This restriction is primarily to
     46     simplify/speed up the compiler (at no loss of generality because vregs
     47     can always be used).  The live ranges of allocatable physregs should be
     48     short, e.g. an instruction selector may emit:
     49 
     50     EAX = vreg1234
     51     EDX = vreg4567
     52     div vreg1928
     53     vreg8910 = EAX
     54 
     55 The set of allocatable physregs can be obtained with 
     56 MRegisterInfo::getAllocatableSet.
     57 
     58 Also, I'd suggest reading through the CodeGen/LiveVariables.cpp file.  It 
     59 is pretty short and describes some of these issues.  Here's the file 
     60 header comment:
     61 
     62 // This file implements the LiveVariable analysis pass.  For each machine
     63 // instruction in the function, this pass calculates the set of registers that
     64 // are immediately dead after the instruction (i.e., the instruction calculates
     65 // the value, but it is never used) and the set of registers that are used by
     66 // the instruction, but are never used after the instruction (i.e., they are
     67 // killed).
     68 //
     69 // This class computes live variables using are sparse implementation based on
     70 // the machine code SSA form.  This class computes live variable information for
     71 // each virtual and _register allocatable_ physical register in a function.  It
     72 // uses the dominance properties of SSA form to efficiently compute live
     73 // variables for virtual registers, and assumes that physical registers are only
     74 // live within a single basic block (allowing it to do a single local analysis
     75 // to resolve physical register lifetimes in each basic block).  If a physical
     76 // register is not register allocatable, it is not tracked.  This is useful for
     77 // things like the stack pointer and condition codes.
     78 
     79 
     80 -Chris
     81 
     82 -- 
     83 http://nondot.org/sabre/
     84 http://llvm.org/
     85