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 + + + +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.
+ +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.
-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.
-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").
-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.
-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.
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:
An invocation frame is layed out as follows (low memory at top);
+An invocation frame is laid out as follows (low memory at top);