This series does some initial work to make expansion of the get_range function a lot cleaner. It also adds a couple simple initial ranges. These patches are by no means perfect, but I hope they will provide some feedback and ideas. I'm hoping to expand this to do the following: -Add get_range for most opcodes I can think of -Add more utility functions to the constant_util file. -Repurpose the file to optimize more than just min/max. -Elimintate if's that we know the result of -Whatever pops into my head
I have some questions about undefined behaviour regarding this. Do we have anyway of signaling in our IR that the variable is the result of undefined behaviour? In compilers like llvm, if I recall, they have a flag for this so they can signal undefined behaviour and use whatever value gives the most efficient code for its uses.(used in -ffast-math). A hypotetichal situation: We find that we have sqrt(x) where x has upper bound < 0. The spec says the behavior is undefined for x < 0. The same applies for inverse sqrt, log, log2 and pow. How should this be handled? Should a warning be issued? Could we simplify this to a constant 0? That would allow more optimizations to occur. Thomas Helland (6): glsl: Move common code to constant_util glsl: Expand constant_util glsl: Change to using switch-case in get_range glsl: Expand get_range to include sin/cos/sign glsl: Add saturate to get_range glsl: Add abs/sqrt/exp to get_range src/glsl/ir_constant_util.h | 134 ++++++++++++++++++++++++++++++++++++++++++++ src/glsl/opt_algebraic.cpp | 95 +------------------------------ src/glsl/opt_minmax.cpp | 73 +++++++++++++++++------- 3 files changed, 189 insertions(+), 113 deletions(-) create mode 100644 src/glsl/ir_constant_util.h -- 2.0.3 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
