From 6de2c08bc400b4aca9fb46684e8bdb56eed9b09f Mon Sep 17 00:00:00 2001 From: dim <dim@FreeBSD.org> Date: Sun, 2 Dec 2012 13:10:19 +0000 Subject: Vendor import of llvm release_32 branch r168974 (effectively, 3.2 RC2): http://llvm.org/svn/llvm-project/llvm/branches/release_32@168974 --- docs/CodeGenerator.rst | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) (limited to 'docs/CodeGenerator.rst') diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst index d1d0231..5fab76e 100644 --- a/docs/CodeGenerator.rst +++ b/docs/CodeGenerator.rst @@ -81,7 +81,7 @@ Required components in the code generator The two pieces of the LLVM code generator are the high-level interface to the code generator and the set of reusable components that can be used to build target-specific backends. The two most important interfaces (:raw-html:`<tt>` -`TargetMachine`_ :raw-html:`</tt>` and :raw-html:`<tt>` `TargetData`_ +`TargetMachine`_ :raw-html:`</tt>` and :raw-html:`<tt>` `DataLayout`_ :raw-html:`</tt>`) are the only ones that are required to be defined for a backend to fit into the LLVM system, but the others must be defined if the reusable code generator components are going to be used. @@ -197,7 +197,7 @@ any particular client. These classes are designed to capture the *abstract* properties of the target (such as the instructions and registers it has), and do not incorporate any particular pieces of code generation algorithms. -All of the target description classes (except the :raw-html:`<tt>` `TargetData`_ +All of the target description classes (except the :raw-html:`<tt>` `DataLayout`_ :raw-html:`</tt>` class) are designed to be subclassed by the concrete target implementation, and have virtual methods implemented. To get to these implementations, the :raw-html:`<tt>` `TargetMachine`_ :raw-html:`</tt>` class @@ -214,18 +214,18 @@ the ``get*Info`` methods (``getInstrInfo``, ``getRegisterInfo``, ``getFrameInfo``, etc.). This class is designed to be specialized by a concrete target implementation (e.g., ``X86TargetMachine``) which implements the various virtual methods. The only required target description class is the -:raw-html:`<tt>` `TargetData`_ :raw-html:`</tt>` class, but if the code +:raw-html:`<tt>` `DataLayout`_ :raw-html:`</tt>` class, but if the code generator components are to be used, the other interfaces should be implemented as well. -.. _TargetData: +.. _DataLayout: -The ``TargetData`` class +The ``DataLayout`` class ------------------------ -The ``TargetData`` class is the only required target description class, and it -is the only class that is not extensible (you cannot derived a new class from -it). ``TargetData`` specifies information about how the target lays out memory +The ``DataLayout`` class is the only required target description class, and it +is the only class that is not extensible (you cannot derive a new class from +it). ``DataLayout`` specifies information about how the target lays out memory for structures, the alignment requirements for various data types, the size of pointers in the target, and whether the target is little-endian or big-endian. @@ -248,7 +248,7 @@ operations. Among other things, this class indicates: * the type to use for shift amounts, and * various high-level characteristics, like whether it is profitable to turn - division by a constant into a multiplication sequence + division by a constant into a multiplication sequence. The ``TargetRegisterInfo`` class -------------------------------- @@ -256,10 +256,10 @@ The ``TargetRegisterInfo`` class 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 -description) are unique small numbers, and virtual registers are generally -large. Note that register ``#0`` is reserved as a flag value. +Registers are represented in the code generator by unsigned integers. Physical +registers (those that actually exist in the target description) are unique +small numbers, and virtual registers are generally large. Note that +register ``#0`` is reserved as a flag value. Each register in the processor description has an associated ``TargetRegisterDesc`` entry, which provides a textual name for the register @@ -390,7 +390,7 @@ functions make it easy to build arbitrary machine instructions. Usage of the MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42); // Create the same instr, but insert it at the end of a basic block. - MachineBasicBlock &MBB = ... + MachineBasicBlock &MBB = ... BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42); // Create the same instr, but insert it before a specified iterator point. @@ -404,7 +404,7 @@ functions make it easy to build arbitrary machine instructions. Usage of the MI = BuildMI(X86::SAHF, 0); // Create a self looping branch instruction. - BuildMI(MBB, X86::JNE, 1).addMBB(&MBB); + BuildMI(MBB, X86::JNE, 1).addMBB(&MBB); The key thing to remember with the ``BuildMI`` functions is that you have to specify the number of operands that the machine instruction will take. This @@ -838,8 +838,7 @@ Initial SelectionDAG Construction ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The initial SelectionDAG is na\ :raw-html:`ï`\ vely peephole expanded from -the LLVM input by the ``SelectionDAGLowering`` class in the -``lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp`` file. The intent of this pass +the LLVM input by the ``SelectionDAGBuilder`` class. The intent of this pass is to expose as much low-level, target-specific details to the SelectionDAG as possible. This pass is mostly hard-coded (e.g. an LLVM ``add`` turns into an ``SDNode add`` while a ``getelementptr`` is expanded into the obvious -- cgit v1.1