The MRegisterInfo class (which will eventually be renamed to -TargetRegisterInfo) is used to describe the register file of the -target and any interactions between the registers.
+The TargetRegisterInfo class is used to describe the register +file of the target and any interactions between the registers.
Registers in the code generator are represented in the code generator by unsigned integers. Physical registers (those that actually exist in the target @@ -395,8 +408,8 @@ register (used for assembly output and debugging dumps) and a set of aliases (used to indicate whether one register overlaps with another).
-In addition to the per-register description, the MRegisterInfo class -exposes a set of processor specific register classes (instances of the +
In addition to the per-register description, the TargetRegisterInfo +class exposes a set of processor specific register classes (instances of the TargetRegisterClass class). Each register class contains sets of registers that have the same properties (for example, they are all 32-bit integer registers). Each SSA virtual register created by the instruction @@ -608,9 +621,9 @@ copies a virtual register into or out of a physical register when needed.
-int %test(int %X, int %Y) {
- %Z = div int %X, %Y
- ret int %Z
+define i32 @test(i32 %X, i32 %Y) {
+ %Z = udiv i32 %X, %Y
+ ret i32 %Z
}
Instruction Selection is the process of translating LLVM code presented to the code generator into target-specific machine instructions. There are several -well-known ways to do this in the literature. In LLVM there are two main forms: -the SelectionDAG based instruction selector framework and an old-style 'simple' -instruction selector, which effectively peephole selects each LLVM instruction -into a series of machine instructions. We recommend that all targets use the -SelectionDAG infrastructure. +well-known ways to do this in the literature. LLVM uses a SelectionDAG based +instruction selector.
Portions of the DAG instruction selector are generated from the target description (*.td) files. Our goal is for the entire instruction -selector to be generated from these .td files.
+selector to be generated from these .td files, though currently +there are still things that require custom C++ code. @@ -780,7 +790,8 @@ to the node defining the used value. Because nodes may define multiple values, edges are represented by instances of the SDOperand class, which is a <SDNode, unsigned> pair, indicating the node and result value being used, respectively. Each value produced by an SDNode has -an associated MVT::ValueType indicating what type the value is. +an associated MVT (Machine Value Type) indicating what the type of the +value is.SelectionDAGs contain two different kinds of values: those that represent data flow and those that represent control flow dependencies. Data values are @@ -852,7 +863,11 @@ of the code compiled (if you only get errors printed to the console while using this, you probably need to configure your system to add support for it). The -view-sched-dags option views the SelectionDAG output from the Select phase and input to the Scheduler -phase.
+phase. The -view-sunit-dags option views the ScheduleDAG, which is +based on the final SelectionDAG, with nodes that must be scheduled as a unit +bundled together into a single node, and with immediate operands and other +nodes that aren't relevent for scheduling omitted. + @@ -1098,11 +1113,12 @@ primarily because it is a work in progress and is not yet finished:To Be Written
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 physical +register are live at the same point in the program (i.e., they conflict). When +this situation occurs, one virtual register must be spilled.
+ +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 register and +register allocatable physical register in the function. This +is done in a very efficient manner because it uses SSA to sparsely +compute 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 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 intervals analysis. If the last basic block +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 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 +basic blocks. If a successor basic block has a PHI node and one of +the PHI node's operands is coming from the current basic block, +then the variable is marked as alive within the current basic block +and all of its predecessor basic blocks, until the basic block with the +defining instruction is encountered.
+ +We now have the information available to perform the live intervals analysis +and build the live intervals themselves. We start off by numbering the basic +blocks and machine instructions. We then handle the "live-in" values. These +are in physical registers, so the physical register is assumed to be killed by +the end of the basic block. Live intervals for virtual registers are computed +for some ordering of the machine instructions [1, N]. A live interval +is an interval [i, j), where 1 <= i <= j < N, for which a +variable is live.
+ +More to come...
+ +The Register Allocation problem consists in mapping a -program Pv, that can use an unbounded number of -virtual registers, to a program Pp that contains a -finite (possibly small) number of physical registers. Each target -architecture has a different number of physical registers. If the -number of physical registers is not enough to accommodate all the -virtual registers, some of them will have to be mapped into -memory. These virtuals are called spilled virtuals.
+The Register Allocation problem consists in mapping a program +Pv, that can use an unbounded number of virtual +registers, to a program Pp that contains a finite +(possibly small) number of physical registers. Each target architecture has +a different number of physical registers. If the number of physical +registers is not enough to accommodate all the virtual registers, some of +them will have to be mapped into memory. These virtuals are called +spilled virtuals.
Physical registers, in LLVM, are grouped in Register Classes. @@ -1211,13 +1308,13 @@ this code can be used:
-bool RegMapping_Fer::compatible_class(MachineFunction &mf,
+bool RegMapping_Fer::compatible_class(MachineFunction &mf,
unsigned v_reg,
unsigned p_reg) {
- assert(MRegisterInfo::isPhysicalRegister(p_reg) &&
+ assert(TargetRegisterInfo::isPhysicalRegister(p_reg) &&
"Target register must be physical");
- const TargetRegisterClass *trc = mf.getSSARegMap()->getRegClass(v_reg);
- return trc->contains(p_reg);
+ const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
+ return trc->contains(p_reg);
}
We will call physical registers present in the LLVM bytecode before +
We will call physical registers present in the LLVM bitcode before register allocation pre-colored registers. Pre-colored registers are used in many different situations, for instance, to pass parameters of functions calls, and to store results of particular @@ -1298,7 +1395,7 @@ overwritten by the values of virtual registers while still alive.
There are two ways to map virtual registers to physical registers (or to memory slots). The first way, that we will call direct mapping, -is based on the use of methods of the classes MRegisterInfo, +is based on the use of methods of the classes TargetRegisterInfo, and MachineOperand. The second way, that we will call indirect mapping, relies on the VirtRegMap class in order to insert loads and stores sending and getting values to and from @@ -1312,8 +1409,8 @@ target function being compiled in order to get and store values in memory. To assign a physical register to a virtual register present in a given operand, use MachineOperand::setReg(p_reg). To insert a store instruction, use -MRegisterInfo::storeRegToStackSlot(...), and to insert a load -instruction, use MRegisterInfo::loadRegFromStackSlot.
+TargetRegisterInfo::storeRegToStackSlot(...), and to insert a load +instruction, use TargetRegisterInfo::loadRegFromStackSlot.The indirect mapping shields the application developer from the
complexities of inserting load and store instructions. In order to map
@@ -1371,12 +1468,12 @@ instance, in situations where an instruction such as %a = ADD %b
%a = MOVE %b
-%a = ADD %a %b
+%a = ADD %a %c
Notice that, internally, the second instruction is represented as -ADD %a[def/use] %b. I.e., the register operand %a is +ADD %a[def/use] %c. I.e., the register operand %a is both used and defined by the instruction.
Instructions can be folded with the -MRegisterInfo::foldMemoryOperand(...) method. Care must be +TargetRegisterInfo::foldMemoryOperand(...) method. Care must be taken when folding instructions; a folded instruction can be quite different from the original instruction. See LiveIntervals::addIntervalsForSpills in @@ -1525,7 +1622,51 @@ are specific to the code generator for a particular target.
+ + +Tail call optimization, callee reusing the stack of the caller, is currently supported on x86/x86-64 and PowerPC. It is performed if: +
x86/x86-64 constraints: +
PowerPC constraints: +
Example:
+Call as llc -tailcallopt test.ll. +
+declare fastcc i32 @tailcallee(i32 inreg %a1, i32 inreg %a2, i32 %a3, i32 %a4)
+
+define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
+ %l1 = add i32 %in1, %in2
+ %tmp = tail call fastcc i32 @tailcallee(i32 %in1 inreg, i32 %in2 inreg, i32 %in1, i32 %l1)
+ ret i32 %tmp
+}
+ Implications of -tailcallopt:
+To support tail call optimization in situations where the callee has more arguments than the caller a 'callee pops arguments' convention is used. This currently causes each fastcc call that is not tail call optimized (because one or more of above constraints are not met) to be followed by a readjustment of the stack. So performance might be worse in such cases.
+On x86 and x86-64 one register is reserved for indirect tail calls (e.g via a function pointer). So there is one less register for integer argument passing. For x86 this means 2 registers (if inreg parameter attribute is used) and for x86-64 this means 5 register are used.
+The X86 code generator lives in the lib/Target/X86 directory. This -code generator currently targets a generic P6-like processor. As such, it -produces a few P6-and-above instructions (like conditional moves), but it does -not make use of newer features like MMX or SSE. In the future, the X86 backend -will have sub-target support added for specific processor families and -implementations.
+code generator is capable of targeting a variety of x86-32 and x86-64 +processors, and includes support for ISA extensions such as MMX and SSE. +The folowing target-specific calling conventions are known to backend:
+ +The PowerPC code generator lives in the lib/Target/PowerPC directory. The +code generation is retargetable to several variations or subtargets of +the PowerPC ISA; including ppc32, ppc64 and altivec. +
+LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC +relative (PIC) or static addressing for accessing global values, so no TOC (r2) +is used. Second, r31 is used as a frame pointer to allow dynamic growth of a +stack frame. LLVM takes advantage of having no TOC to provide space to save +the frame pointer in the PowerPC linkage area of the caller frame. Other +details of PowerPC ABI can be found at PowerPC ABI. Note: This link describes the 32 bit ABI. The +64 bit ABI is similar except space for GPRs are 8 bytes wide (not 4) and r13 is +reserved for system use.
+The size of a PowerPC frame is usually fixed for the duration of a +function’s invocation. Since the frame is fixed size, all references into +the frame can be accessed via fixed offsets from the stack pointer. The +exception to this is when dynamic alloca or variable sized arrays are present, +then a base pointer (r31) is used as a proxy for the stack pointer and stack +pointer is free to grow or shrink. A base pointer is also used if llvm-gcc is +not passed the -fomit-frame-pointer flag. The stack pointer is always aligned to +16 bytes, so that space allocated for altivec vectors will be properly +aligned.
+An invocation frame is layed out as follows (low memory at top);
+| Linkage |
+
| Parameter area |
+
| Dynamic area |
+
| Locals area |
+
| Saved registers area |
+
| Previous Frame |
+
The linkage area is used by a callee to save special registers prior +to allocating its own frame. Only three entries are relevant to LLVM. The +first entry is the previous stack pointer (sp), aka link. This allows probing +tools like gdb or exception handlers to quickly scan the frames in the stack. A +function epilog can also use the link to pop the frame from the stack. The +third entry in the linkage area is used to save the return address from the lr +register. Finally, as mentioned above, the last entry is used to save the +previous frame pointer (r31.) The entries in the linkage area are the size of a +GPR, thus the linkage area is 24 bytes long in 32 bit mode and 48 bytes in 64 +bit mode.
+32 bit linkage area
+| 0 | +Saved SP (r1) | +
| 4 | +Saved CR | +
| 8 | +Saved LR | +
| 12 | +Reserved | +
| 16 | +Reserved | +
| 20 | +Saved FP (r31) | +
64 bit linkage area
+| 0 | +Saved SP (r1) | +
| 8 | +Saved CR | +
| 16 | +Saved LR | +
| 24 | +Reserved | +
| 32 | +Reserved | +
| 40 | +Saved FP (r31) | +
The parameter area is used to store arguments being passed to a callee +function. Following the PowerPC ABI, the first few arguments are actually +passed in registers, with the space in the parameter area unused. However, if +there are not enough registers or the callee is a thunk or vararg function, +these register arguments can be spilled into the parameter area. Thus, the +parameter area must be large enough to store all the parameters for the largest +call sequence made by the caller. The size must also be mimimally large enough +to spill registers r3-r10. This allows callees blind to the call signature, +such as thunks and vararg functions, enough space to cache the argument +registers. Therefore, the parameter area is minimally 32 bytes (64 bytes in 64 +bit mode.) Also note that since the parameter area is a fixed offset from the +top of the frame, that a callee can access its spilt arguments using fixed +offsets from the stack pointer (or base pointer.)
+Combining the information about the linkage, parameter areas and alignment. A +stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit +mode.
+The dynamic area starts out as size zero. If a function uses dynamic +alloca then space is added to the stack, the linkage and parameter areas are +shifted to top of stack, and the new space is available immediately below the +linkage and parameter areas. The cost of shifting the linkage and parameter +areas is minor since only the link value needs to be copied. The link value can +be easily fetched by adding the original frame size to the base pointer. Note +that allocations in the dynamic space need to observe 16 byte aligment.
+The locals area is where the llvm compiler reserves space for local +variables.
+The saved registers area is where the llvm compiler spills callee saved +registers on entry to the callee.
+The llvm prolog and epilog are the same as described in the PowerPC ABI, with +the following exceptions. Callee saved registers are spilled after the frame is +created. This allows the llvm epilog/prolog support to be common with other +targets. The base pointer callee saved register r31 is saved in the TOC slot of +linkage area. This simplifies allocation of space for the base pointer and +makes it convenient to locate programatically and during debugging.
+TODO - More to come.
+