[Mesa-dev] Mesa (shader-work): glsl: add pass to lower variable array indexing to conditional assignments
luca at luca-barbieri.com
Mon Sep 13 18:45:22 PDT 2010
> I think you forgot to include this file in this commit.
> This is one that I was going to give some review comments on. I really
> want to have this change in 7.9, but the patch is going to need some
> changes. When we first discussed using C++ in the GLSL compiler in
> Mesa, we got some feedback about C++ features not to use. The main ones
> on the list are:
> - RTTI
> - Operator overloading
> - Multiple / virtual inheritance
> - Templates
I would suggest to avoid banning any feature, and instead allow all of
them (in C++03 + TR1, until we decide that C++0x is OK too) and decide
in each instance whether it is being used appropriately or not.
That said, I removed both templates and operator overloading from the pass.
Note that templates are often essential to write generic code and
build collection classes.
Also, I think you should start using the STL: there are several parts
of the compilers that could use a std::map or std::unordered_map and
are doing linear scans instead, resulting in potential catastrophic
slowdown in pathological cases (e.g. finding induction variables).
exec_node and exec_list should also take template parameters for the
next/prev pointers: this would make the code more type-safe.
RTTI is probably a better replacement for the as_IR_TYPE() functions:
they can be written as dynamic_cast<IR_TYPE*>(foo) instead, or
&dynamic_cast<IR_TYPE&>(*foo) if you want an exception on failure.
Operator overloading can be essential in the places where it is
natural (e.g. defining a type that can hold all possible numeric types
of a language).
Overloading the call operator avoids needing to introduce an
unnecessary function name.
Multiple / virtual inheritance is indeed best to use rarely: I can't
think of any use of it in the current compiler.
Exceptions are another possible "contentious" feature.
> Based on my memory of the code, it should be pretty easy to eliminate
> the use of templates.
Yes, it's trivial, since the current code always uses the same
parameter, and I did it in the current committed code. I also removed
The best long-term solution would however be to add an ir_switch node
and put the "switch_generator" code in a lowering pass for it.
Recent version of GLSL have a switch construct anyway.
Note that the current switch_generator only handles sequential cases
and would need to be extended to non-sequential ones.
This is nontrivial if empty fallthroughs are allowed because binary
search doesn't always work (e.g. case 1: case 3: a(); break; case 2:
More information about the mesa-dev