diff options
Diffstat (limited to 'gnu/llvm/docs/WritingAnLLVMBackend.rst')
| -rw-r--r-- | gnu/llvm/docs/WritingAnLLVMBackend.rst | 90 |
1 files changed, 44 insertions, 46 deletions
diff --git a/gnu/llvm/docs/WritingAnLLVMBackend.rst b/gnu/llvm/docs/WritingAnLLVMBackend.rst index fdadbb04e94..f0f3ab5504d 100644 --- a/gnu/llvm/docs/WritingAnLLVMBackend.rst +++ b/gnu/llvm/docs/WritingAnLLVMBackend.rst @@ -135,14 +135,13 @@ First, you should create a subdirectory under ``lib/Target`` to hold all the files related to your target. If your target is called "Dummy", create the directory ``lib/Target/Dummy``. -In this new directory, create a ``Makefile``. It is easiest to copy a -``Makefile`` of another target and modify it. It should at least contain the -``LEVEL``, ``LIBRARYNAME`` and ``TARGET`` variables, and then include -``$(LEVEL)/Makefile.common``. The library can be named ``LLVMDummy`` (for -example, see the MIPS target). Alternatively, you can split the library into -``LLVMDummyCodeGen`` and ``LLVMDummyAsmPrinter``, the latter of which should be -implemented in a subdirectory below ``lib/Target/Dummy`` (for example, see the -PowerPC target). +In this new directory, create a ``CMakeLists.txt``. It is easiest to copy a +``CMakeLists.txt`` of another target and modify it. It should at least contain +the ``LLVM_TARGET_DEFINITIONS`` variable. The library can be named ``LLVMDummy`` +(for example, see the MIPS target). Alternatively, you can split the library +into ``LLVMDummyCodeGen`` and ``LLVMDummyAsmPrinter``, the latter of which +should be implemented in a subdirectory below ``lib/Target/Dummy`` (for example, +see the PowerPC target). Note that these two naming schemes are hardcoded into ``llvm-config``. Using any other naming scheme will confuse ``llvm-config`` and produce a lot of @@ -156,13 +155,12 @@ generator, you should do what all current machine backends do: create a subclass of ``LLVMTargetMachine``. (To create a target from scratch, create a subclass of ``TargetMachine``.) -To get LLVM to actually build and link your target, you need to add it to the -``TARGETS_TO_BUILD`` variable. To do this, you modify the configure script to -know about your target when parsing the ``--enable-targets`` option. Search -the configure script for ``TARGETS_TO_BUILD``, add your target to the lists -there (some creativity required), and then reconfigure. Alternatively, you can -change ``autoconf/configure.ac`` and regenerate configure by running -``./autoconf/AutoRegen.sh``. +To get LLVM to actually build and link your target, you need to run ``cmake`` +with ``-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Dummy``. This will build your +target without needing to add it to the list of all the targets. + +Once your target is stable, you can add it to the ``LLVM_ALL_TARGETS`` variable +located in the main ``CMakeLists.txt``. Target Machine ============== @@ -347,7 +345,7 @@ to define an object for each register. The specified string ``n`` becomes the ``Name`` of the register. The basic ``Register`` object does not have any subregisters and does not specify any aliases. -.. code-block:: llvm +.. code-block:: text class Register<string n> { string Namespace = ""; @@ -363,7 +361,7 @@ subregisters and does not specify any aliases. For example, in the ``X86RegisterInfo.td`` file, there are register definitions that utilize the ``Register`` class, such as: -.. code-block:: llvm +.. code-block:: text def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>; @@ -416,7 +414,7 @@ classes. In ``Target.td``, the ``Register`` class is the base for the ``RegisterWithSubRegs`` class that is used to define registers that need to specify subregisters in the ``SubRegs`` list, as shown here: -.. code-block:: llvm +.. code-block:: text class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n> { let SubRegs = subregs; @@ -429,7 +427,7 @@ feature common to these subclasses. Note the use of "``let``" expressions to override values that are initially defined in a superclass (such as ``SubRegs`` field in the ``Rd`` class). -.. code-block:: llvm +.. code-block:: text class SparcReg<string n> : Register<n> { field bits<5> Num; @@ -454,7 +452,7 @@ field in the ``Rd`` class). In the ``SparcRegisterInfo.td`` file, there are register definitions that utilize these subclasses of ``Register``, such as: -.. code-block:: llvm +.. code-block:: text def G0 : Ri< 0, "G0">, DwarfRegNum<[0]>; def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>; @@ -480,7 +478,7 @@ default allocation order of the registers. A target description file ``XXXRegisterInfo.td`` that uses ``Target.td`` can construct register classes using the following class: -.. code-block:: llvm +.. code-block:: text class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, dag regList> { @@ -534,7 +532,7 @@ defines a group of 32 single-precision floating-point registers (``F0`` to ``F31``); ``DFPRegs`` defines a group of 16 double-precision registers (``D0-D15``). -.. code-block:: llvm +.. code-block:: text // F0, F1, F2, ..., F31 def FPRegs : RegisterClass<"SP", [f32], 32, (sequence "F%u", 0, 31)>; @@ -705,7 +703,7 @@ which describes one instruction. An instruction descriptor defines: The Instruction class (defined in ``Target.td``) is mostly used as a base for more complex instruction classes. -.. code-block:: llvm +.. code-block:: text class Instruction { string Namespace = ""; @@ -762,7 +760,7 @@ specific operation value for ``LD``/Load Word. The third parameter is the output destination, which is a register operand and defined in the ``Register`` target description file (``IntRegs``). -.. code-block:: llvm +.. code-block:: text def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr), "ld [$addr], $dst", @@ -771,7 +769,7 @@ target description file (``IntRegs``). The fourth parameter is the input source, which uses the address operand ``MEMrr`` that is defined earlier in ``SparcInstrInfo.td``: -.. code-block:: llvm +.. code-block:: text def MEMrr : Operand<i32> { let PrintMethod = "printMemOperand"; @@ -790,7 +788,7 @@ immediate value operands. For example, to perform a Load Integer instruction for a Word from an immediate operand to a register, the following instruction class is defined: -.. code-block:: llvm +.. code-block:: text def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr), "ld [$addr], $dst", @@ -803,7 +801,7 @@ creation of templates to define several instruction classes at once (using the pattern ``F3_12`` is defined to create 2 instruction classes each time ``F3_12`` is invoked: -.. code-block:: llvm +.. code-block:: text multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> { def rr : F3_1 <2, Op3Val, @@ -820,7 +818,7 @@ So when the ``defm`` directive is used for the ``XOR`` and ``ADD`` instructions, as seen below, it creates four instruction objects: ``XORrr``, ``XORri``, ``ADDrr``, and ``ADDri``. -.. code-block:: llvm +.. code-block:: text defm XOR : F3_12<"xor", 0b000011, xor>; defm ADD : F3_12<"add", 0b000000, add>; @@ -832,7 +830,7 @@ For example, the 10\ :sup:`th` bit represents the "greater than" condition for integers, and the 22\ :sup:`nd` bit represents the "greater than" condition for floats. -.. code-block:: llvm +.. code-block:: text def ICC_NE : ICC_VAL< 9>; // Not Equal def ICC_E : ICC_VAL< 1>; // Equal @@ -857,7 +855,7 @@ order they are defined. Fields are bound when they are assigned a value. For example, the Sparc target defines the ``XNORrr`` instruction as a ``F3_1`` format instruction having three operands. -.. code-block:: llvm +.. code-block:: text def XNORrr : F3_1<2, 0b000111, (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), @@ -867,7 +865,7 @@ format instruction having three operands. The instruction templates in ``SparcInstrFormats.td`` show the base class for ``F3_1`` is ``InstSP``. -.. code-block:: llvm +.. code-block:: text class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { field bits<32> Inst; @@ -882,7 +880,7 @@ The instruction templates in ``SparcInstrFormats.td`` show the base class for ``InstSP`` leaves the ``op`` field unbound. -.. code-block:: llvm +.. code-block:: text class F3<dag outs, dag ins, string asmstr, list<dag> pattern> : InstSP<outs, ins, asmstr, pattern> { @@ -899,7 +897,7 @@ The instruction templates in ``SparcInstrFormats.td`` show the base class for fields. ``F3`` format instructions will bind the operands ``rd``, ``op3``, and ``rs1`` fields. -.. code-block:: llvm +.. code-block:: text class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins, string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> { @@ -927,7 +925,7 @@ TableGen definition will add all of its operands to an enumeration in the llvm::XXX:OpName namespace and also add an entry for it into the OperandMap table, which can be queried using getNamedOperandIdx() -.. code-block:: llvm +.. code-block:: text int DstIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::dst); // => 0 int BIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::b); // => 1 @@ -974,7 +972,7 @@ For example, the X86 backend defines ``brtarget`` and ``brtarget8``, both instances of the TableGen ``Operand`` class, which represent branch target operands: -.. code-block:: llvm +.. code-block:: text def brtarget : Operand<OtherVT>; def brtarget8 : Operand<OtherVT>; @@ -1224,14 +1222,14 @@ definitions in ``XXXInstrInfo.td``. For example, in ``SparcInstrInfo.td``, this entry defines a register store operation, and the last parameter describes a pattern with the store DAG operator. -.. code-block:: llvm +.. code-block:: text def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src), "st $src, [$addr]", [(store i32:$src, ADDRrr:$addr)]>; ``ADDRrr`` is a memory mode that is also defined in ``SparcInstrInfo.td``: -.. code-block:: llvm +.. code-block:: text def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>; @@ -1242,7 +1240,7 @@ defined in an implementation of the Instructor Selector (such as In ``lib/Target/TargetSelectionDAG.td``, the DAG operator for store is defined below: -.. code-block:: llvm +.. code-block:: text def store : PatFrag<(ops node:$val, node:$ptr), (st node:$val, node:$ptr), [{ @@ -1460,7 +1458,7 @@ if the current argument is of type ``f32`` or ``f64``), then the action is performed. In this case, the ``CCAssignToReg`` action assigns the argument value to the first available register: either ``R0`` or ``R1``. -.. code-block:: llvm +.. code-block:: text CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>> @@ -1471,7 +1469,7 @@ which registers are used for specified scalar return types. A single-precision float is returned to register ``F0``, and a double-precision float goes to register ``D0``. A 32-bit integer is returned in register ``I0`` or ``I1``. -.. code-block:: llvm +.. code-block:: text def RetCC_Sparc32 : CallingConv<[ CCIfType<[i32], CCAssignToReg<[I0, I1]>>, @@ -1486,7 +1484,7 @@ the size of the slot, and the second parameter, also 4, indicates the stack alignment along 4-byte units. (Special cases: if size is zero, then the ABI size is used; if alignment is zero, then the ABI alignment is used.) -.. code-block:: llvm +.. code-block:: text def CC_Sparc32 : CallingConv<[ // All arguments get passed in integer registers if there is space. @@ -1501,7 +1499,7 @@ the following example (in ``X86CallingConv.td``), the definition of assigned to the register ``ST0`` or ``ST1``, the ``RetCC_X86Common`` is invoked. -.. code-block:: llvm +.. code-block:: text def RetCC_X86_32_C : CallingConv<[ CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>, @@ -1516,7 +1514,7 @@ then a specified action is invoked. In the following example (in ``RetCC_X86_32_Fast`` is invoked. If the ``SSECall`` calling convention is in use, then ``RetCC_X86_32_SSE`` is invoked. -.. code-block:: llvm +.. code-block:: text def RetCC_X86_32 : CallingConv<[ CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>, @@ -1684,7 +1682,7 @@ feature, the value of the attribute, and a description of the feature. (The fifth parameter is a list of features whose presence is implied, and its default value is an empty array.) -.. code-block:: llvm +.. code-block:: text class SubtargetFeature<string n, string a, string v, string d, list<SubtargetFeature> i = []> { @@ -1698,7 +1696,7 @@ default value is an empty array.) In the ``Sparc.td`` file, the ``SubtargetFeature`` is used to define the following features. -.. code-block:: llvm +.. code-block:: text def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true", "Enable SPARC-V9 instructions">; @@ -1712,7 +1710,7 @@ Elsewhere in ``Sparc.td``, the ``Proc`` class is defined and then is used to define particular SPARC processor subtypes that may have the previously described features. -.. code-block:: llvm +.. code-block:: text class Proc<string Name, list<SubtargetFeature> Features> : Processor<Name, NoItineraries, Features>; |