I think my patch can be seen an intermediate step towards that.
I'm not sure that it's a good idea to implement them in terms of all/any.
ir_binop_all_equal and ir_binop_any_nequal represent the concept of
"whole object equality", which seems quite useful in itself.
For instance, it can be trivially extended to records and any other
data structure, while the all()/any() approach is more cumbersome in
that case.
> Using ir_unop_any, we get stuck with:
>
> bvec4 a = bvec4(true, true, x > y, true);
> if (!any(not(a))) {
> ...
> }
>
> It never gets reduced because an expression is either completely
> constant or it's not constant at all.
Perhaps this should be fixed.
But in general I'm wondering whether attempting to write a great
optimizer for GLSL IR is a good idea, or whether we should just
convert the GLSL IR to LLVM, let the LLVM optimizers do their job and
then convert back until all hardware has an LLVM backend.
In particular, I suspect that writing an optimizer that can decently
handle long and complex OpenGL 4.1 shaders using
EXT_shader_image_load_store, or OpenCL compute shaders (which come as
LLVM IR anyway), and a code generator that can truly generate optimal
hardware code, will need as much work as writing GCC or LLVM from
scratch.
I (mostly) did the GLSL->LLVM conversion code, but the other side,
which is harder, is still missing.
Why did you not choose to not do that straight away, and instead opted
for writing GLSL IR optimization passes?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
