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 @@ -407,8 +407,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 @@ -718,8 +718,7 @@ comes from.
corresponds one-to-one with the LLVM function input to the instruction selector. In addition to a list of basic blocks, the MachineFunction contains a a MachineConstantPool, a MachineFrameInfo, a -MachineFunctionInfo, a SSARegMap, and a set of live in and -live out registers for the function. See +MachineFunctionInfo, and a MachineRegisterInfo. See include/llvm/CodeGen/MachineFunction.h for more information.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. @@ -864,7 +861,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. + @@ -1110,11 +1111,12 @@ primarily because it is a work in progress and is not yet finished:More to come...
- - @@ -1292,7 +1291,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. @@ -1307,13 +1306,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 @@ -1394,7 +1393,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 +1407,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 @@ -1529,7 +1528,7 @@ instance, a sequence of instructions such as:
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 @@ -1630,11 +1629,9 @@ are specific to the code generator for a particular target.
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 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 +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 @@ -1942,7 +1939,9 @@ makes it convenient to locate programatically and during debugging.
TODO - More to come.
+