I just remembered the existence of this series so I went ahead and tried it on top of today's master. With NIR enabled there is no benefit at all, didn't try without NIR. I've marked it as rejected in patchwork, so it's not floating around in there. <div class="gmail_quote">3. jan. 2015 20.21 skrev "Thomas Helland" <<a href="mailto:thomashelland90@gmail.com">thomashelland90@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I couple months ago i posted a series for expanding the get_range function in minmax_pruning with support for more operations. So I've been hacking on this during my spare time in Christmas. I've now gotten to a point where I think this is not getting us anywhere, and I need some opinions from other devs to prove me wrong. As it stands only a couple of these patches yield any results, and IMHO only the first patch is merge-material until we can confirm that this is actually gonna give is significant improvements. The first patch gives noticeable improvements on shader-db since we are no longer messing up our saturate-detection. Patches up to patch 9 are quite small, and patch 5 yeilds some benefit one some Dungeon Defenders shaders that do max(exp, 0). These might be merge-material to, due to their small size. However the benefits of patch 5 could easily be had with a 10-line patch to opt_algebraic, and that's the only one showing any benefit on my collection of shaders. Patches 10-19 take on more complexity, with no apparent benefit. I feel theres not adequate return on investement for the code to be sitting around bloating the codebase. The last three patches are RFC only, as we at least need to rename the file to something more generic before merging them. There is still room for improvement, but I'm not sure its worth it. Maybe someone can do a shader-db run that proves me wrong? My shader-db is dominated by TF2, DOTA2, Portal, Brutal Legend and Dungeon Defenders. Maybe non-Source-engine games show some benefit from this series? I'm not comfortable with how this might mess up our shaders. It gets hard to verify that things end up complying to spec, and that we are not doing something wrong. Some lerp-instructions got removed in Brutal Legend (it could be guaranteed that the operation would be saturated to 1), and while I could tell it was likely that the pass was doing the right thing, it was not easily confirmable. This worries me. IMHO we need to do better for this to be worth it. I added a print to the get_range function to gather some stats: 2 million calls are made to get_range on my shader-db run. 500'000 of these are expressions, 2'000 of these are unsupported. 350'000 of these are constants. So our coverage in get_range is less than 50%. Is there anything more we could get/know the range of? Thomas Helland (22): glsl: Reorder optimization-passes glsl: Move common code to ir_constant_util.h glsl: Add a IS_CONSTANT macro glsl: Change to using switch-case in get_range glsl: Add sqrt, rsq, exp, exp2 to get_range glsl: Add sin, cos and sign to get_range glsl: Add saturate to get_range glsl: Add abs to get_range glsl: Add ir_unop_neg to get_range glsl: Add ir_binop_add to get_range glsl: Add ir_binop_mul to get_range glsl: Add ir_binop_sub to get_range glsl: Add ir_binop_pow to get_range glsl: Add ir_triop_fma to get_range glsl: Add ir_triop_lrp to get_range glsl: Add ir_binop_dot to get_range glsl: Add log and log2 to get_range glsl: Add ir_unop_rcp to get_range glsl: Add a saturate range optimization glsl: Optimize some cases of undefined behaviour. glsl: Add a range based comparison opt-pass glsl: Remove useless abs based on range analysis src/glsl/glsl_parser_extras.cpp | 2 +- src/glsl/ir_constant_util.h | 110 +++++++++ src/glsl/opt_algebraic.cpp | 93 +------- src/glsl/opt_minmax.cpp | 495 ++++++++++++++++++++++++++++++++++++++-- 4 files changed, 589 insertions(+), 111 deletions(-) create mode 100644 src/glsl/ir_constant_util.h -- 2.2.1 </blockquote></div>