From 641b279710f85924c72c542698d4340c2626d9a1 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Mon, 24 Nov 2008 16:27:17 +0000 Subject: [PATCH] Some documentation for LegalizeTypes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59962 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CodeGenerator.html | 132 ++++++++++++++++++++++++---------------- 1 file changed, 78 insertions(+), 54 deletions(-) diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index a43baee56e6..10d2de3d83f 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -50,6 +50,7 @@ Process
  • Initial SelectionDAG Construction
    • +
  • SelectionDAG LegalizeTypes Phase
  • SelectionDAG Legalize Phase
  • SelectionDAG Optimization Phase: the DAG Combiner
    • @@ -813,8 +814,9 @@ basic block function it would be the return node.

    operations and supported types. On a 32-bit PowerPC, for example, a DAG with a value of type i1, i8, i16, or i64 would be illegal, as would a DAG that uses a SREM or UREM operation. The -legalize phase is responsible for turning -an illegal DAG into a legal DAG.

    +legalize types and +legalize operations phases are +responsible for turning an illegal DAG into a legal DAG.

    @@ -837,12 +839,18 @@ an illegal DAG into a legal DAG.

    pairs) for targets that support these meta operations. This makes the resultant code more efficient and the select instructions from DAG phase (below) simpler. -
  • Legalize SelectionDAG - This stage - converts the illegal SelectionDAG to a legal SelectionDAG by eliminating - unsupported operations and data types.
    • -
  • Optimize SelectionDAG (#2) - This - second run of the SelectionDAG optimizes the newly legalized DAG to - eliminate inefficiencies introduced by legalization.
    • +
  • Legalize SelectionDAG Types - This + stage transforms SelectionDAG nodes to eliminate any types that are + unsupported on the target.
    • +
  • Optimize SelectionDAG - The + SelectionDAG optimizer is run to clean up redundancies exposed + by type legalization.
    • +
  • Legalize SelectionDAG Types - This + stage transforms SelectionDAG nodes to eliminate any types that are + unsupported on the target.
    • +
  • Optimize SelectionDAG - The + SelectionDAG optimizer is run to eliminate inefficiencies introduced + by operation legalization.
  • Select instructions from DAG - Finally, the target instruction selector matches the DAG operations to target instructions. This process translates the target-independent input DAG into @@ -876,7 +884,7 @@ add support for it).

    The -view-sunit-dags displays the Scheduler's dependency graph. This graph is based on the final SelectionDAG, with nodes that must be scheduled together bundled into a single scheduling-unit node, and with -immediate operands and other nodes that aren't relevent for scheduling +immediate operands and other nodes that aren't relevant for scheduling omitted.

    @@ -901,6 +909,40 @@ returns, varargs, etc. For these features, the + +
    + SelectionDAG LegalizeTypes Phase +
    + +
    + +

    The Legalize phase is in charge of converting a DAG to only use the types +that are natively supported by the target.

    + +

    There are two main ways of converting values of unsupported scalar types + to values of supported types: converting small types to + larger types ("promoting"), and breaking up large integer types + into smaller ones ("expanding"). For example, a target might require + that all f32 values are promoted to f64 and that all i1/i8/i16 values + are promoted to i32. The same target might require that all i64 values + be expanded into pairs of i32 values. These changes can insert sign and + zero extensions as needed to make sure that the final code has the same + behavior as the input.

    + +

    There are two main ways of converting values of unsupported vector types + to value of supported types: splitting vector types, multiple times if + necessary, until a legal type is found, and extending vector types by + adding elements to the end to round them out to legal types ("widening"). + If a vector gets split all the way down to single-element parts with + no supported vector type being found, the elements are converted to + scalars ("scalarizing").

    + +

    A target implementation tells the legalizer which types are supported + (and which register class to use for them) by calling the + addRegisterClass method in its TargetLowering constructor.

    + +
    +
    SelectionDAG Legalize Phase @@ -908,46 +950,28 @@ returns, varargs, etc. For these features, the
    -

    The Legalize phase is in charge of converting a DAG to only use the types and -operations that are natively supported by the target. This involves two major -tasks:

    +

    The Legalize phase is in charge of converting a DAG to only use the +operations that are natively supported by the target.

    -
      -

    1. Convert values of unsupported types to values of supported types.

      -

      There are two main ways of doing this: converting small types to - larger types ("promoting"), and breaking up large integer types - into smaller ones ("expanding"). For example, a target might require - that all f32 values are promoted to f64 and that all i1/i8/i16 values - are promoted to i32. The same target might require that all i64 values - be expanded into i32 values. These changes can insert sign and zero - extensions as needed to make sure that the final code has the same - behavior as the input.

      -

      A target implementation tells the legalizer which types are supported - (and which register class to use for them) by calling the - addRegisterClass method in its TargetLowering constructor.

      -
      2. +

      Targets often have weird constraints, such as not supporting every + operation on every supported datatype (e.g. X86 does not support byte + conditional moves and PowerPC does not support sign-extending loads from + a 16-bit memory location). Legalize takes care of this by open-coding + another sequence of operations to emulate the operation ("expansion"), by + promoting one type to a larger type that supports the operation + ("promotion"), or by using a target-specific hook to implement the + legalization ("custom").

      -

    2. Eliminate operations that are not supported by the target.

      -

      Targets often have weird constraints, such as not supporting every - operation on every supported datatype (e.g. X86 does not support byte - conditional moves and PowerPC does not support sign-extending loads from - a 16-bit memory location). Legalize takes care of this by open-coding - another sequence of operations to emulate the operation ("expansion"), by - promoting one type to a larger type that supports the operation - ("promotion"), or by using a target-specific hook to implement the - legalization ("custom").

      -

      A target implementation tells the legalizer which operations are not - supported (and which of the above three actions to take) by calling the - setOperationAction method in its TargetLowering - constructor.

      -
      3. -
    +

    A target implementation tells the legalizer which operations are not + supported (and which of the above three actions to take) by calling the + setOperationAction method in its TargetLowering + constructor.

    -

    Prior to the existance of the Legalize pass, we required that every target +

    Prior to the existence of the Legalize passes, we required that every target selector supported and handled every operator and type even if they are not natively supported. The introduction of -the Legalize phase allows all of the cannonicalization patterns to be shared -across targets, and makes it very easy to optimize the cannonicalized code +the Legalize phases allows all of the canonicalization patterns to be shared +across targets, and makes it very easy to optimize the canonicalized code because it is still in the form of a DAG.

    @@ -960,12 +984,12 @@ because it is still in the form of a DAG.

    -

    The SelectionDAG optimization phase is run twice for code generation: once -immediately after the DAG is built and once after legalization. The first run -of the pass allows the initial code to be cleaned up (e.g. performing +

    The SelectionDAG optimization phase is run multiple times for code generation, +immediately after the DAG is built and once after each legalization. The first +run of the pass allows the initial code to be cleaned up (e.g. performing optimizations that depend on knowing that the operators have restricted type -inputs). The second run of the pass cleans up the messy code generated by the -Legalize pass, which allows Legalize to be very simple (it can focus on making +inputs). Subsequent runs of the pass clean up the messy code generated by the +Legalize passes, which allows Legalize to be very simple (it can focus on making code legal instead of focusing on generating good and legal code).

    One important class of optimizations performed is optimizing inserted sign @@ -1228,7 +1252,7 @@ values in the function.

    PHI nodes need to be handled specially, because the calculation of the live variable information from a depth first traversal of the CFG of the function won't guarantee that a virtual register used by the PHI -node is defined before it's used. When a PHI node is encounted, only +node is defined before it's used. When a PHI node is encountered, only the definition is handled, because the uses will be handled in other basic blocks.

    @@ -1722,7 +1746,7 @@ that people test.

    -

    The folowing target-specific calling conventions are known to backend:

    +

    The following target-specific calling conventions are known to backend:

    • x86_StdCall - stdcall calling convention seen on Microsoft Windows @@ -1829,7 +1853,7 @@ pointer is free to grow or shrink. A base pointer is also used if llvm-gcc is not passed the -fomit-frame-pointer flag. The stack pointer is always aligned to 16 bytes, so that space allocated for altivec vectors will be properly aligned.

      -

      An invocation frame is layed out as follows (low memory at top);

      +

      An invocation frame is laid out as follows (low memory at top);

    @@ -1938,7 +1962,7 @@ passed in registers, with the space in the parameter area unused. However, if there are not enough registers or the callee is a thunk or vararg function, these register arguments can be spilled into the parameter area. Thus, the parameter area must be large enough to store all the parameters for the largest -call sequence made by the caller. The size must also be mimimally large enough +call sequence made by the caller. The size must also be minimally large enough to spill registers r3-r10. This allows callees blind to the call signature, such as thunks and vararg functions, enough space to cache the argument registers. Therefore, the parameter area is minimally 32 bytes (64 bytes in 64 @@ -1960,7 +1984,7 @@ shifted to top of stack, and the new space is available immediately below the linkage and parameter areas. The cost of shifting the linkage and parameter areas is minor since only the link value needs to be copied. The link value can be easily fetched by adding the original frame size to the base pointer. Note -that allocations in the dynamic space need to observe 16 byte aligment.

    +that allocations in the dynamic space need to observe 16 byte alignment.