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

[Christoph Bumiller]

On 06.08.2013 19:19, Matt Turner wrote:
> On Tue, Aug 6, 2013 at 4:14 AM, Christoph Bumiller
> <e0425955 at student.tuwien.ac.at> 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 ?
> We would love that. As part of an work in progress, I'm adding
> conditional-select to the GLSL IR. We planned a few months ago to do
> this as a step toward SSA at the IR level, but have only laid a little
> bit of groundwork in that direction (Ian's vector insert/extract
> series).
>
> Looks like your backend already does SSA. Shouldn't that be
> implemented in common code? :)

Then the code would have to run on GLSL IR as well as my internal IR
because the intermediate one, TGSI, shouldn't be in SSA form, and
abstracting an IR doesn't sound particularly fun.
Also I don't have to handle vectors so it's a bit simpler, actually
pretty straightforward if you implement an existing algorithm.
As for some other passes that could be shared, I still need them in the
backend to be applied to device-specifc code sequences, you probably
have a similar situation.

>> 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).
> Yes, it definitely would.