X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FExtendingLLVM.html;h=647fa01d53bbca054ea108d0e1259f39f93c7d65;hb=1ac022974a75aaccc11d9f7f024044cba7ee99f8;hp=6aece2ff9ce7a0ebd014896cc4caac69d001aa58;hpb=a424228023cb0f420e4bea6011aaa8df80e9d1c5;p=oota-llvm.git diff --git a/docs/ExtendingLLVM.html b/docs/ExtendingLLVM.html index 6aece2ff9ce..647fa01d53b 100644 --- a/docs/ExtendingLLVM.html +++ b/docs/ExtendingLLVM.html @@ -16,6 +16,7 @@
  • Introduction and Warning
  • Adding a new intrinsic function
  • Adding a new instruction
  • +
  • Adding a new SelectionDAG node
  • Adding a new type
    1. Adding a new fundamental type
    2. @@ -24,8 +25,9 @@
    -

    Written by Misha Brukman and - Brad Jones

    +

    Written by Misha Brukman, + Brad Jones, Nate Begeman, + and Chris Lattner

    @@ -51,9 +53,9 @@ different passes that you intend to use with your extension, and there are many LLVM analyses and transformations, so it may be quite a bit of work.

    -

    Adding an intrinsic function is easier than adding -an instruction, and is transparent to optimization passes which treat it as an -unanalyzable function. If your added functionality can be expressed as a +

    Adding an intrinsic function is far easier than +adding an instruction, and is transparent to optimization passes. If your added +functionality can be expressed as a function call, an intrinsic function is the method of choice for LLVM extension.

    @@ -83,34 +85,137 @@ function and then be turned into an instruction if warranted.

    what the restrictions are. Talk to other people about it so that you are sure it's a good idea.
  • -
  • llvm/include/llvm/Intrinsics.h: - add an enum in the llvm::Intrinsic namespace
  • +
  • llvm/include/llvm/Intrinsics*.td: + Add an entry for your intrinsic. Describe its memory access characteristics + for optimization (this controls whether it will be DCE'd, CSE'd, etc). Note + that any intrinsic using the llvm_int_ty type for an argument will + be deemed by tblgen as overloaded and the corresponding suffix + will be required on the intrinsic's name.
  • -
  • llvm/lib/CodeGen/IntrinsicLowering.cpp: - implement the lowering for this intrinsic
  • +
  • llvm/lib/Analysis/ConstantFolding.cpp: If it is possible to + constant fold your intrinsic, add support to it in the + canConstantFoldCallTo and ConstantFoldCall functions.
  • -
  • llvm/lib/VMCore/Verifier.cpp: - Add code to check the invariants of the intrinsic are respected.
  • +
  • llvm/test/Regression/*: Add test cases for your test cases to the + test suite
  • + -
  • llvm/lib/VMCore/Function.cpp (Function::getIntrinsicID()): - Identify the new intrinsic function, returning the enum for the intrinsic - that you added.
  • +

    Once the intrinsic has been added to the system, you must add code generator +support for it. Generally you must do the following steps:

    + +
    +
    Add support to the C backend in lib/Target/CBackend/
    + +
    Depending on the intrinsic, there are a few ways to implement this. For + most intrinsics, it makes sense to add code to lower your intrinsic in + LowerIntrinsicCall in lib/CodeGen/IntrinsicLowering.cpp. + Second, if it makes sense to lower the intrinsic to an expanded sequence of + C code in all cases, just emit the expansion in visitCallInst in + Writer.cpp. If the intrinsic has some way to express it with GCC + (or any other compiler) extensions, it can be conditionally supported based + on the compiler compiling the CBE output (see llvm.prefetch for an + example). Third, if the intrinsic really has no way to be lowered, just + have the code generator emit code that prints an error message and calls + abort if executed.
    + +
    Add support to the .td file for the target(s) of your choice in + lib/Target/*/*.td.
    + +
    This is usually a matter of adding a pattern to the .td file that matches + the intrinsic, though it may obviously require adding the instructions you + want to generate as well. There are lots of examples in the PowerPC and X86 + backend to follow.
    +
    -
  • llvm/lib/Analysis/BasicAliasAnalysis.cpp: If the new intrinsic does - not access memory or does not write to memory, add it to the relevant list - of functions.
  • + -
  • llvm/lib/Transforms/Utils/Local.cpp: If it is possible to - constant-propagate your intrinsic, add support to it in the - canConstantFoldCallTo and ConstantFoldCall functions.
  • + +
    + Adding a new SelectionDAG node +
    + -
  • Test your intrinsic
  • +
    -
  • llvm/test/Regression/*: add your test cases to the test suite
  • - +

    As with intrinsics, adding a new SelectionDAG node to LLVM is much easier +than adding a new instruction. New nodes are often added to help represent +instructions common to many targets. These nodes often map to an LLVM +instruction (add, sub) or intrinsic (byteswap, population count). In other +cases, new nodes have been added to allow many targets to perform a common task +(converting between floating point and integer representation) or capture more +complicated behavior in a single node (rotate).

    -

    If this intrinsic requires code generator support (i.e., it cannot be -lowered), you should also add support to the code generator in question.

    +
      +
    1. include/llvm/CodeGen/SelectionDAGNodes.h: + Add an enum value for the new SelectionDAG node.
    2. +
    3. lib/CodeGen/SelectionDAG/SelectionDAG.cpp: + Add code to print the node to getOperationName. If your new node + can be evaluated at compile time when given constant arguments (such as an + add of a constant with another constant), find the getNode method + that takes the appropriate number of arguments, and add a case for your node + to the switch statement that performs constant folding for nodes that take + the same number of arguments as your new node.
    4. +
    5. lib/CodeGen/SelectionDAG/LegalizeDAG.cpp: + Add code to legalize, + promote, and expand the node as necessary. At a minimum, you will need + to add a case statement for your node in LegalizeOp which calls + LegalizeOp on the node's operands, and returns a new node if any of the + operands changed as a result of being legalized. It is likely that not all + targets supported by the SelectionDAG framework will natively support the + new node. In this case, you must also add code in your node's case + statement in LegalizeOp to Expand your node into simpler, legal + operations. The case for ISD::UREM for expanding a remainder into + a divide, multiply, and a subtract is a good example.
    6. +
    7. lib/CodeGen/SelectionDAG/LegalizeDAG.cpp: + If targets may support the new node being added only at certain sizes, you + will also need to add code to your node's case statement in + LegalizeOp to Promote your node's operands to a larger size, and + perform the correct operation. You will also need to add code to + PromoteOp to do this as well. For a good example, see + ISD::BSWAP, + which promotes its operand to a wider size, performs the byteswap, and then + shifts the correct bytes right to emulate the narrower byteswap in the + wider type.
    8. +
    9. lib/CodeGen/SelectionDAG/LegalizeDAG.cpp: + Add a case for your node in ExpandOp to teach the legalizer how to + perform the action represented by the new node on a value that has been + split into high and low halves. This case will be used to support your + node with a 64 bit operand on a 32 bit target.
    10. +
    11. lib/CodeGen/SelectionDAG/DAGCombiner.cpp: + If your node can be combined with itself, or other existing nodes in a + peephole-like fashion, add a visit function for it, and call that function + from . There are several good examples for simple combines you + can do; visitFABS and visitSRL are good starting places. +
    12. +
    13. lib/Target/PowerPC/PPCISelLowering.cpp: + Each target has an implementation of the TargetLowering class, + usually in its own file (although some targets include it in the same + file as the DAGToDAGISel). The default behavior for a target is to + assume that your new node is legal for all types that are legal for + that target. If this target does not natively support your node, then + tell the target to either Promote it (if it is supported at a larger + type) or Expand it. This will cause the code you wrote in + LegalizeOp above to decompose your new node into other legal + nodes for this target.
    14. +
    15. lib/Target/TargetSelectionDAG.td: + Most current targets supported by LLVM generate code using the DAGToDAG + method, where SelectionDAG nodes are pattern matched to target-specific + nodes, which represent individual instructions. In order for the targets + to match an instruction to your new node, you must add a def for that node + to the list in this file, with the appropriate type constraints. Look at + add, bswap, and fadd for examples.
    16. +
    17. lib/Target/PowerPC/PPCInstrInfo.td: + Each target has a tablegen file that describes the target's instruction + set. For targets that use the DAGToDAG instruction selection framework, + add a pattern for your new node that uses one or more target nodes. + Documentation for this is a bit sparse right now, but there are several + decent examples. See the patterns for rotl in + PPCInstrInfo.td.
    18. +
    19. TODO: document complex patterns.
    20. +
    21. llvm/test/Regression/CodeGen/*: Add test cases for your new node + to the test suite. llvm/test/Regression/CodeGen/X86/bswap.ll is + a good example.
    22. +
    @@ -122,7 +227,7 @@ lowered), you should also add support to the code generator in question.

    -

    WARNING: adding instructions changes the bytecode +

    WARNING: adding instructions changes the bitcode format, and it will take some effort to maintain compatibility with the previous version. Only add an instruction if it is absolutely necessary.

    @@ -145,8 +250,8 @@ necessary.

    add the grammar on how your instruction can be read and what it will construct as a result -
  • llvm/lib/Bytecode/Reader/Reader.cpp: - add a case for your instruction and how it will be parsed from bytecode
  • +
  • llvm/lib/Bitcode/Reader/Reader.cpp: + add a case for your instruction and how it will be parsed from bitcode
  • llvm/lib/VMCore/Instruction.cpp: add a case for how your instruction will be printed out to assembly
  • @@ -179,7 +284,7 @@ to understand this new instruction.

    -

    WARNING: adding new types changes the bytecode +

    WARNING: adding new types changes the bitcode format, and will break compatibility with currently-existing LLVM installations. Only add new types if it is absolutely necessary.

    @@ -194,11 +299,8 @@ installations. Only add new types if it is absolutely necessary.

      -
    1. llvm/include/llvm/Type.def: - add enum for the type
    2. -
    3. llvm/include/llvm/Type.h: - add ID number for the new type; add static Type* for this type
    4. + add enum for the new type; add static Type* for this type
    5. llvm/lib/VMCore/Type.cpp: add mapping from TypeID => Type*; @@ -222,14 +324,11 @@ installations. Only add new types if it is absolutely necessary.

        -
      1. llvm/include/llvm/Type.def: - add enum for the type
      2. -
      3. llvm/include/llvm/Type.h: - add ID number for the new type; add a forward declaration of the type + add enum for the new type; add a forward declaration of the type also
      4. -
      5. llvm/include/llvm/DerivedType.h: +
      6. llvm/include/llvm/DerivedTypes.h: add new class to represent new class in the hierarchy; add forward declaration to the TypeMap value type
      7. @@ -248,12 +347,12 @@ bool TypesEqual(const Type *Ty, const Type *Ty2,
      8. llvm/lib/AsmReader/Lexer.l: add ability to parse in the type from text assembly
      9. -
      10. llvm/lib/ByteCode/Writer/Writer.cpp: - modify void BytecodeWriter::outputType(const Type *T) to serialize +
      11. llvm/lib/BitCode/Writer/Writer.cpp: + modify void BitcodeWriter::outputType(const Type *T) to serialize your type
      12. -
      13. llvm/lib/ByteCode/Reader/Reader.cpp: - modify const Type *BytecodeReader::ParseType() to read your data +
      14. llvm/lib/BitCode/Reader/Reader.cpp: + modify const Type *BitcodeReader::ParseType() to read your data type
      15. llvm/lib/VMCore/AsmWriter.cpp: @@ -279,12 +378,11 @@ void calcTypeName(const Type *Ty,
        Valid CSS! + src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"> Valid HTML 4.01! + src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> - Misha Brukman
        - The LLVM Compiler Infrastructure + The LLVM Compiler Infrastructure
        Last modified: $Date$