From: Francisco Jerez Date: Wed, 9 Mar 2016 08:32:13 +0000 (-0800) Subject: intel/compiler: Define more detailed analysis dependency classes X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=65080dc8df00d006912ade2d69d4a06c3d4c5e0a;p=mesa.git intel/compiler: Define more detailed analysis dependency classes I've deliberately separated this from the general analysis pass infrastructure in order to discuss it independently. The dependency classes defined here refer to state changes of several objects of the program IR, and are fully orthogonal and expected to change less often than the set of analysis passes present in the compiler back-end. The objective is to avoid unnecessary coupling between optimization and analysis passes in the back-end. By doing things in this way the set of flags to be passed to invalidate_analysis() can be determined from knowledge of a single optimization pass and a small set of well specified dependency classes alone -- IOW there is no need to audit all analysis passes to find out which ones might be affected by certain kind of program transformation performed by an optimization pass, as well as the converse, there is no need to audit all optimization passes when writing a new analysis pass to find out which ones can potentially invalidate the result of the analysis. The set of dependency classes defined here is rather conservative and mainly based on the requirements of the few analysis passes already part of the back-end. I've also used them without difficulty with a few additional analysis passes I've written but haven't yet sent for review. Reviewed-by: Matt Turner Part-of: --- diff --git a/src/intel/compiler/brw_ir_analysis.h b/src/intel/compiler/brw_ir_analysis.h index d2a984ab96b..360b2f70735 100644 --- a/src/intel/compiler/brw_ir_analysis.h +++ b/src/intel/compiler/brw_ir_analysis.h @@ -36,6 +36,52 @@ namespace brw { * constant during the compilation. */ DEPENDENCY_NOTHING = 0, + /** + * The analysis depends on the set of instructions in the program and + * their naming. Note that because instructions are named sequentially + * by IP this implies a dependency on the control flow edges between + * instructions. This will be signaled whenever instructions are + * inserted, removed or reordered in the program. + */ + DEPENDENCY_INSTRUCTION_IDENTITY = 0x1, + /** + * The analysis is sensitive to the detailed semantics of instructions + * in the program, where "detailed" means any change in the instruction + * data structures other than the linked-list pointers (which are + * already covered by DEPENDENCY_INSTRUCTION_IDENTITY). E.g. changing + * the negate or abs flags of an instruction source would signal this + * flag alone because it would preserve all other instruction dependency + * classes. + */ + DEPENDENCY_INSTRUCTION_DETAIL = 0x2, + /** + * The analysis depends on the set of data flow edges between + * instructions. This will be signaled whenever the dataflow relation + * between instructions has potentially changed, e.g. when the VGRF + * index of an instruction source or destination changes (in which case + * it will appear in combination with DEPENDENCY_INSTRUCTION_DETAIL), or + * when data-dependent instructions are reordered (in which case it will + * appear in combination with DEPENDENCY_INSTRUCTION_IDENTITY). + */ + DEPENDENCY_INSTRUCTION_DATA_FLOW = 0x4, + /** + * The analysis depends on all instruction dependency classes. These + * will typically be signaled simultaneously when inserting or removing + * instructions in the program (or if you're feeling too lazy to read + * through your optimization pass to figure out which of the instruction + * dependency classes above it invalidates). + */ + DEPENDENCY_INSTRUCTIONS = 0x7, + /** + * The analysis depends on the set of VGRFs in the program and their + * naming. This will be signaled when VGRFs are allocated or released. + */ + DEPENDENCY_VARIABLES = 0x8, + /** + * The analysis depends on the set of basic blocks in the program, their + * control flow edges and naming. + */ + DEPENDENCY_BLOCKS = 0x10, /** * The analysis depends on the program being literally the same (good * luck...), any change in the input invalidates previous analysis