[Mesa-dev] [PATCH 13/30] i965/ir: Define more detailed analysis dependency classes.

[Francisco Jerez]

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.
---
 src/mesa/drivers/dri/i965/brw_ir_analysis.h | 46 +++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_ir_analysis.h b/src/mesa/drivers/dri/i965/brw_ir_analysis.h
index 31989ec..f008ac7 100644
--- a/src/mesa/drivers/dri/i965/brw_ir_analysis.h
+++ b/src/mesa/drivers/dri/i965/brw_ir_analysis.h
@@ -37,6 +37,52 @@ namespace brw {
        */
       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
        * computations.
-- 
2.7.0