X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FExtendingLLVM.html;h=647fa01d53bbca054ea108d0e1259f39f93c7d65;hb=ab7c09b6b6f4516a631fd6788918c237c83939af;hp=dbfd4b8ec703577dacafd0ac155f38e3e4622c18;hpb=2f86c223d3bc4976eb5171a55df3e0eac4247a2e;p=oota-llvm.git diff --git a/docs/ExtendingLLVM.html b/docs/ExtendingLLVM.html index dbfd4b8ec70..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. @@ -25,7 +26,8 @@

      Written by Misha Brukman, - Brad Jones, and Chris Lattner

      + 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,31 +85,19 @@ 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. -
    2. llvm/include/llvm/Intrinsics.h: - add an enum in the llvm::Intrinsic namespace
      3. - -
    3. llvm/lib/VMCore/Verifier.cpp: - Add code to check the invariants of the intrinsic are respected.
      4. - -
    4. llvm/lib/VMCore/Function.cpp (Function::getIntrinsicID()): - Identify the new intrinsic function, returning the enum for the intrinsic - that you added.
      5. - -
    5. 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.
      6. +
    6. 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.
    7. llvm/lib/Analysis/ConstantFolding.cpp: If it is possible to constant fold your intrinsic, add support to it in the canConstantFoldCallTo and ConstantFoldCall functions.
      8. -
    8. llvm/lib/Transforms/Utils/Local.cpp: If your intrinsic has no side- - effects, add it to the list of intrinsics in the - isInstructionTriviallyDead function.
      9. - -
    9. Test your intrinsic
      10. - -
    10. llvm/test/Regression/*: add your test cases to the test suite
      11. +
    11. llvm/test/Regression/*: Add test cases for your test cases to the + test suite

    Once the intrinsic has been added to the system, you must add code generator @@ -116,48 +106,116 @@ 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. First, -if it makes sense to lower the intrinsic to an expanded sequence of C code in -all cases, just emit the expansion in visitCallInst. Second, 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 a enum value for the SelectionDAG node in -include/llvm/CodeGen/SelectionDAGNodes.h
    - -
    Also, add code to lib/CodeGen/SelectionDAG/SelectionDAG.cpp (and -SelectionDAGPrinter.cpp) to print the node.
    - -
    Add code to SelectionDAG/SelectionDAGISel.cpp to recognize the -intrinsic.
    - -
    Presumably the intrinsic should be recognized and turned into the node you -added above.
    +
    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.
    +
    -
    Add code to SelectionDAG/LegalizeDAG.cpp to legalize, promote, and -expand the node as necessary.
    + -
    If the intrinsic can be expanded to primitive operations, legalize can break -the node down into other elementary operations that are be supported.
    + +
    + Adding a new SelectionDAG node +
    + -
    Add target-specific support to specific code generators.
    +
    -
    Extend the code generators you are interested in to recognize and support -the node, emitting the code you want.
    - +

    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).

    -

    -Unfortunately, the process of extending the code generator to support a new node -is not extremely well documented. As such, it is often helpful to look at other -intrinsics (e.g. llvm.ctpop) to see how they are recognized and turned -into a node by SelectionDAGISel.cpp, legalized by -LegalizeDAG.cpp, then finally emitted by the various code generators. -

    +
      +
    1. include/llvm/CodeGen/SelectionDAGNodes.h: + Add an enum value for the new SelectionDAG node.
      2. +
    2. 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.
      3. +
    3. 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.
      4. +
    4. 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.
      5. +
    5. 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.
      6. +
    6. 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. +
      7. +
    7. 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.
      8. +
    8. 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.
      9. +
    9. 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.
      10. +
    10. TODO: document complex patterns.
      11. +
    11. 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.
      12. +
    @@ -169,7 +227,7 @@ into a node by SelectionDAGISel.cpp, legalized by
    -

    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.

    @@ -192,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
    • @@ -226,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.

    @@ -289,12 +347,12 @@ bool TypesEqual(const Type *Ty, const Type *Ty2,
  • llvm/lib/AsmReader/Lexer.l: add ability to parse in the type from text assembly
    • -
  • llvm/lib/ByteCode/Writer/Writer.cpp: - modify void BytecodeWriter::outputType(const Type *T) to serialize +
  • llvm/lib/BitCode/Writer/Writer.cpp: + modify void BitcodeWriter::outputType(const Type *T) to serialize your type
    • -
  • llvm/lib/ByteCode/Reader/Reader.cpp: - modify const Type *BytecodeReader::ParseType() to read your data +
  • llvm/lib/BitCode/Reader/Reader.cpp: + modify const Type *BitcodeReader::ParseType() to read your data type
  • llvm/lib/VMCore/AsmWriter.cpp: @@ -320,11 +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"> - The LLVM Compiler Infrastructure + The LLVM Compiler Infrastructure
    Last modified: $Date$