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