[Mesa-dev] [PATCH 4/6] i965/fs: Optimize IF/MOV/ELSE/MOV/ENDIF to SEL when possible.

[Ian Romanick]

On 08/06/2013 02:17 PM, Kenneth Graunke wrote:
> On 08/06/2013 04:14 AM, Christoph Bumiller wrote:
>> On 06.08.2013 03:28, Kenneth Graunke wrote:
>>> Many GLSL shaders contain code of the form:
>>>
>>>     x = condition ? foo : bar
>>>
>>> The compiler emits an ir_if tree for this, since each subexpression
>>> might be a complex tree that could have side-effects and short-circuit
>>> logic operations.
>>>
>>> However, the common case is to simply pick one of two constants or
>>> variable's values---which is exactly what SEL is for.  Replacing IF/ELSE
>>> with SEL also simplifies the control flow graph, making optimization
>>> passes which work on basic blocks more effective.
>>>
>>
>> Don't you think something like that should be implemented in common code
>> so that all drivers can profit ?
>>
>> It would be really nice to have more, useful device-independent
>> optimizations or simplifications like this already done instead of
>> requiring each driver to re-implement them (or use llvm).
>
> I agree - I'd love to have more optimizations in the common code.  But
> it's rather awkward to implement them now due to our tree-like IR.
>
> For example, if I created an ir_triop_sel expression, it would take
> three ir_rvalues as operands.  If I let those be arbitrary expresion
> trees, then ir_triop_sel couldn't map to SEL in basically any hardware,
> and so backends would need to codegen them as if-ladders.  Awkward.
>
> Or, if I forced ir_triop_sel to only take constants and...dereferences
> of variables?...it might map to hardware SEL, but it wouldn't match any
> of the rest of the IR, so enforcing those restrictions would probably be
> awkward.

I've thought a bit about this.  I believe this could / should be handled 
in a couple ways... as should some of the constraints that we already have.

1. Formalize the notion of IR "levels" or languages.  We started with 
this as the plan (having HIR and MIR), but, in our rush, quickly 
deviated from that plan.  A big part of this is just documenting the 
concept and documenting which ir_instruction subclasses can occur in 
which languages.

2. Augment ir_validate to validate the constraints of different 
languages.  If we have multiple languages that share the same data types 
but differing restrictions (e.g., in a low-level IR operands can only be 
ir_constant or ir_dereference), the validator should enforce that.

3. Implement specific passes to translate from one language to another. 
  Use the validator at both ends to enforce the constraints.  Create a 
large number of unit tests to exercise the conversions.

> The tree IR is actually pretty cumbersome to work with.  I was going to
> implement CSE in the main GLSL compiler, but realized there's no
> sensible way to even compare two IR expression trees right now.  My code
> started diverging pretty significantly from the algorithm in the
> textbook, and that seemed bad.
>
> My hope is to eventually create a 3-src style IR for the compiler which
> is SSA and doesn't have trees.  SSA would mean use/def and liveness is
> trivial, and with use/def and 3-src, most compiler optimization passes
> should translate pretty easily.  The idea would be to treat the current
> GLSL IR as "HIR" (a high level IR), and generate the new low-level IR
> ("LIR").  Then, we'd generate i965 assembly from LIR, and probably TGSI
> as well.

If we start with a reasonable picture of where we'd like to end, I think 
we can do a lot of this incrementally.  Borrowing from my steps above, 
we could write a "tree flattening" pass that would convert the existing 
IR to a flat IR using the same data types.

> But that's mostly in the "wouldn't it be great" file for now...in the
> meantime, it's just a lot easier to write optimizations in the backend.
>
> --Ken
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev