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

[Kenneth Graunke]

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.

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.

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