X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FCodeGenerator.html;h=06c6e9ae04652bafba3262c3ae7454095ed948c1;hb=35b9a7790e904abce4e6dac3f1ed89696522f19a;hp=7be4689562bbe37bbff0f3396ece8055a0a375e4;hpb=534bcfb270d25d2a29759d19981443fee7260e94;p=oota-llvm.git diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 7be4689562b..06c6e9ae046 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -26,7 +26,7 @@
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 @@ -408,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 @@ -621,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 }
SelectionDAGs contain two different kinds of values: those that represent data flow and those that represent control flow dependencies. Data values are @@ -1292,7 +1293,7 @@ X86 architecture, the registers EAX, AX and marked as aliased in LLVM. Given a particular architecture, you can check which registers are aliased by inspecting its RegisterInfo.td file. Moreover, the method -MRegisterInfo::getAliasSet(p_reg) returns an array containing +TargetRegisterInfo::getAliasSet(p_reg) returns an array containing all the physical registers aliased to the register p_reg.
Physical registers, in LLVM, are grouped in Register Classes. @@ -1310,7 +1311,7 @@ this code can be used: 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.getRegInfo().getRegClass(v_reg); return trc->contains(p_reg); @@ -1335,9 +1336,9 @@ physical registers, different virtual registers never share the same number. The smallest virtual register is normally assigned the number 1024. This may change, so, in order to know which is the first virtual register, you should access -MRegisterInfo::FirstVirtualRegister. Any register whose +TargetRegisterInfo::FirstVirtualRegister. Any register whose number is greater than or equal to -MRegisterInfo::FirstVirtualRegister is considered a virtual +TargetRegisterInfo::FirstVirtualRegister is considered a virtual register. Whereas physical registers are statically defined in a TargetRegisterInfo.td file and cannot be created by the application developer, that is not the case with virtual registers. @@ -1394,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 @@ -1408,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
@@ -1467,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 @@ -1621,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.
+