A new static version takes an ir_expression_operation enum, and the
original non-static version now uses it. This will make it easier to
read operations (where the ir_expression doesn't yet exist).
This can be useful for debugging - it allows us to see that the inferred
type is what we think it should be. Furthermore, it will allow the IR
reader to avoid complex, operator-specific type inference.
Among other things, this ensures that all of the extension flags are
initially disabled.
This causes the following tests to pass:
glslparsertest/glsl2/draw_buffers-02.frag
The missing else-statements caused all of the extensions execpt
GL_ARB_texture_rectangle to be unsupported.
This causes the following tests to pass:
glslparsertest/glsl2/draw_buffers-04.frag
Previously, the body of some vector constructors were added to the wrong
function signature, and the body of matrix constructors were just being
dumped in the main instruction stream.
Now, ir_function is emitted as part of the IR instructions, rather than
simply existing in the symbol table. Individual ir_function_signatures
are not emitted themselves, but only as part of ir_function.
This pass only works on assignments where the variable is never
referenced. There is no code flow analysis, so it can't do a better
job of avoiding redundant assignments.
For now, the optimizer only does do_dead_code_unlinked(), so it won't
trim the builtin variable list or initializers outside of the scope of
functions. This is because we don't have the visibility into other
functions that might get linked in in order to eliminate work on
global variables.
This will be important to optimization passes. We don't want to
dead-code eliminate writes to out varyings, or propagate uninitialized
values of uniforms.
This is relatively simple at the moment, recognizing only constant
values, and not (for example) values that are restricted to a range
that make the branching constant. However, it does remove 59 lines
from the printout of CorrectParse2.vert.
Previously, generating inlined function bodies was going to be
difficult, as there was no mapping between the body's declaration of
variables where parameter values were supposed to live and the
parameter variables that a caller would use in paramater setup.
Presumably this also have been a problem for actual codegen.
