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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
