2010-07-19 09:36:43 -07:00
|
|
|
/*
|
|
|
|
|
* Copyright © 2010 Intel Corporation
|
|
|
|
|
*
|
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
*
|
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
|
* Software.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
|
* DEALINGS IN THE SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
2010-11-17 10:43:10 -08:00
|
|
|
* \file lower_if_to_cond_assign.cpp
|
2010-07-19 09:36:43 -07:00
|
|
|
*
|
2016-07-03 17:11:07 +02:00
|
|
|
* This flattens if-statements to conditional assignments if:
|
|
|
|
|
*
|
|
|
|
|
* - the GPU has limited or no flow control support
|
|
|
|
|
* (controlled by max_depth)
|
|
|
|
|
*
|
|
|
|
|
* - small conditional branches are more expensive than conditional assignments
|
|
|
|
|
* (controlled by min_branch_cost, that's the cost for a branch to be
|
|
|
|
|
* preserved)
|
2010-07-19 09:36:43 -07:00
|
|
|
*
|
|
|
|
|
* It can't handle other control flow being inside of its block, such
|
|
|
|
|
* as calls or loops. Hopefully loop unrolling and inlining will take
|
|
|
|
|
* care of those.
|
2010-12-27 00:22:38 -08:00
|
|
|
*
|
|
|
|
|
* Drivers for GPUs with no control flow support should simply call
|
|
|
|
|
*
|
|
|
|
|
* lower_if_to_cond_assign(instructions)
|
|
|
|
|
*
|
|
|
|
|
* to attempt to flatten all if-statements.
|
|
|
|
|
*
|
|
|
|
|
* Some GPUs (such as i965 prior to gen6) do support control flow, but have a
|
|
|
|
|
* maximum nesting depth N. Drivers for such hardware can call
|
|
|
|
|
*
|
|
|
|
|
* lower_if_to_cond_assign(instructions, N)
|
|
|
|
|
*
|
|
|
|
|
* to attempt to flatten any if-statements appearing at depth > N.
|
2010-07-19 09:36:43 -07:00
|
|
|
*/
|
|
|
|
|
|
2016-01-18 11:35:29 +02:00
|
|
|
#include "compiler/glsl_types.h"
|
2010-07-19 09:36:43 -07:00
|
|
|
#include "ir.h"
|
2016-08-16 22:10:28 +02:00
|
|
|
#include "util/set.h"
|
|
|
|
|
#include "util/hash_table.h" /* Needed for the hashing functions */
|
2016-07-03 17:11:07 +02:00
|
|
|
#include "main/macros.h" /* for MAX2 */
|
2010-07-19 09:36:43 -07:00
|
|
|
|
2013-09-20 11:03:44 -07:00
|
|
|
namespace {
|
|
|
|
|
|
2010-07-19 09:36:43 -07:00
|
|
|
class ir_if_to_cond_assign_visitor : public ir_hierarchical_visitor {
|
|
|
|
|
public:
|
2016-07-03 17:01:09 +02:00
|
|
|
ir_if_to_cond_assign_visitor(gl_shader_stage stage,
|
2016-07-03 17:11:07 +02:00
|
|
|
unsigned max_depth,
|
|
|
|
|
unsigned min_branch_cost)
|
2010-07-19 09:36:43 -07:00
|
|
|
{
|
|
|
|
|
this->progress = false;
|
2016-07-03 17:01:09 +02:00
|
|
|
this->stage = stage;
|
2010-12-27 00:22:38 -08:00
|
|
|
this->max_depth = max_depth;
|
2016-07-03 17:11:07 +02:00
|
|
|
this->min_branch_cost = min_branch_cost;
|
2010-12-27 00:22:38 -08:00
|
|
|
this->depth = 0;
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
|
2016-08-16 22:10:28 +02:00
|
|
|
this->condition_variables =
|
|
|
|
|
_mesa_set_create(NULL, _mesa_hash_pointer,
|
|
|
|
|
_mesa_key_pointer_equal);
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
~ir_if_to_cond_assign_visitor()
|
|
|
|
|
{
|
2016-08-16 22:10:28 +02:00
|
|
|
_mesa_set_destroy(this->condition_variables, NULL);
|
2010-07-19 09:36:43 -07:00
|
|
|
}
|
|
|
|
|
|
2010-12-27 00:22:38 -08:00
|
|
|
ir_visitor_status visit_enter(ir_if *);
|
2010-07-19 09:36:43 -07:00
|
|
|
ir_visitor_status visit_leave(ir_if *);
|
|
|
|
|
|
2016-07-03 14:57:20 +02:00
|
|
|
bool found_unsupported_op;
|
2016-07-03 17:11:07 +02:00
|
|
|
bool found_expensive_op;
|
|
|
|
|
bool is_then;
|
2010-07-19 09:36:43 -07:00
|
|
|
bool progress;
|
2016-07-03 17:01:09 +02:00
|
|
|
gl_shader_stage stage;
|
2016-07-03 17:11:07 +02:00
|
|
|
unsigned then_cost;
|
|
|
|
|
unsigned else_cost;
|
|
|
|
|
unsigned min_branch_cost;
|
2010-12-27 00:22:38 -08:00
|
|
|
unsigned max_depth;
|
|
|
|
|
unsigned depth;
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
|
2016-08-16 22:10:28 +02:00
|
|
|
struct set *condition_variables;
|
2010-07-19 09:36:43 -07:00
|
|
|
};
|
|
|
|
|
|
2013-09-20 11:03:44 -07:00
|
|
|
} /* anonymous namespace */
|
|
|
|
|
|
2010-07-19 09:36:43 -07:00
|
|
|
bool
|
2016-07-03 17:01:09 +02:00
|
|
|
lower_if_to_cond_assign(gl_shader_stage stage, exec_list *instructions,
|
2016-07-03 17:11:07 +02:00
|
|
|
unsigned max_depth, unsigned min_branch_cost)
|
2010-07-19 09:36:43 -07:00
|
|
|
{
|
2011-10-18 15:04:37 -07:00
|
|
|
if (max_depth == UINT_MAX)
|
|
|
|
|
return false;
|
|
|
|
|
|
2016-07-03 17:11:07 +02:00
|
|
|
ir_if_to_cond_assign_visitor v(stage, max_depth, min_branch_cost);
|
2010-07-19 09:36:43 -07:00
|
|
|
|
|
|
|
|
visit_list_elements(&v, instructions);
|
|
|
|
|
|
|
|
|
|
return v.progress;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2016-07-03 15:03:54 +02:00
|
|
|
check_ir_node(ir_instruction *ir, void *data)
|
2010-07-19 09:36:43 -07:00
|
|
|
{
|
2016-07-03 14:57:20 +02:00
|
|
|
ir_if_to_cond_assign_visitor *v = (ir_if_to_cond_assign_visitor *)data;
|
|
|
|
|
|
2010-07-19 09:36:43 -07:00
|
|
|
switch (ir->ir_type) {
|
|
|
|
|
case ir_type_call:
|
|
|
|
|
case ir_type_discard:
|
|
|
|
|
case ir_type_loop:
|
|
|
|
|
case ir_type_loop_jump:
|
|
|
|
|
case ir_type_return:
|
2016-07-03 15:03:54 +02:00
|
|
|
case ir_type_emit_vertex:
|
|
|
|
|
case ir_type_end_primitive:
|
|
|
|
|
case ir_type_barrier:
|
2016-07-03 14:57:20 +02:00
|
|
|
v->found_unsupported_op = true;
|
2010-07-19 09:36:43 -07:00
|
|
|
break;
|
2016-07-03 17:01:09 +02:00
|
|
|
|
|
|
|
|
case ir_type_dereference_variable: {
|
|
|
|
|
ir_variable *var = ir->as_dereference_variable()->variable_referenced();
|
|
|
|
|
|
|
|
|
|
/* Lowering branches with TCS output accesses breaks many piglit tests,
|
|
|
|
|
* so don't touch them for now.
|
|
|
|
|
*/
|
|
|
|
|
if (v->stage == MESA_SHADER_TESS_CTRL &&
|
|
|
|
|
var->data.mode == ir_var_shader_out)
|
|
|
|
|
v->found_unsupported_op = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-03 17:11:07 +02:00
|
|
|
/* SSBO, images, atomic counters are handled by ir_type_call */
|
|
|
|
|
case ir_type_texture:
|
|
|
|
|
v->found_expensive_op = true;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ir_type_expression:
|
|
|
|
|
case ir_type_dereference_array:
|
|
|
|
|
case ir_type_dereference_record:
|
|
|
|
|
if (v->is_then)
|
|
|
|
|
v->then_cost++;
|
|
|
|
|
else
|
|
|
|
|
v->else_cost++;
|
|
|
|
|
break;
|
|
|
|
|
|
2010-07-19 09:36:43 -07:00
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
move_block_to_cond_assign(void *mem_ctx,
|
2011-08-01 13:28:11 -07:00
|
|
|
ir_if *if_ir, ir_rvalue *cond_expr,
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
exec_list *instructions,
|
2016-08-16 22:10:28 +02:00
|
|
|
struct set *set)
|
2010-07-19 09:36:43 -07:00
|
|
|
{
|
2014-06-24 21:58:35 -07:00
|
|
|
foreach_in_list_safe(ir_instruction, ir, instructions) {
|
2010-07-19 09:36:43 -07:00
|
|
|
if (ir->ir_type == ir_type_assignment) {
|
|
|
|
|
ir_assignment *assign = (ir_assignment *)ir;
|
|
|
|
|
|
2016-08-16 22:10:28 +02:00
|
|
|
if (_mesa_set_search(set, assign) == NULL) {
|
|
|
|
|
_mesa_set_add(set, assign);
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
|
|
|
|
|
/* If the LHS of the assignment is a condition variable that was
|
|
|
|
|
* previously added, insert an additional assignment of false to
|
|
|
|
|
* the variable.
|
|
|
|
|
*/
|
|
|
|
|
const bool assign_to_cv =
|
2016-08-16 22:10:28 +02:00
|
|
|
_mesa_set_search(
|
|
|
|
|
set, assign->lhs->variable_referenced()) != NULL;
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
|
|
|
|
|
if (!assign->condition) {
|
2016-08-16 22:10:28 +02:00
|
|
|
if (assign_to_cv) {
|
|
|
|
|
assign->rhs =
|
|
|
|
|
new(mem_ctx) ir_expression(ir_binop_logic_and,
|
|
|
|
|
glsl_type::bool_type,
|
|
|
|
|
cond_expr->clone(mem_ctx, NULL),
|
|
|
|
|
assign->rhs);
|
|
|
|
|
} else {
|
|
|
|
|
assign->condition = cond_expr->clone(mem_ctx, NULL);
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
assign->condition =
|
2016-08-16 22:10:28 +02:00
|
|
|
new(mem_ctx) ir_expression(ir_binop_logic_and,
|
|
|
|
|
glsl_type::bool_type,
|
|
|
|
|
cond_expr->clone(mem_ctx, NULL),
|
|
|
|
|
assign->condition);
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
}
|
2010-07-19 09:36:43 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Now, move from the if block to the block surrounding it. */
|
|
|
|
|
ir->remove();
|
|
|
|
|
if_ir->insert_before(ir);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-27 00:22:38 -08:00
|
|
|
ir_visitor_status
|
|
|
|
|
ir_if_to_cond_assign_visitor::visit_enter(ir_if *ir)
|
|
|
|
|
{
|
|
|
|
|
(void) ir;
|
|
|
|
|
this->depth++;
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
|
2010-12-27 00:22:38 -08:00
|
|
|
return visit_continue;
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-19 09:36:43 -07:00
|
|
|
ir_visitor_status
|
|
|
|
|
ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
|
|
|
|
|
{
|
2016-07-03 17:11:07 +02:00
|
|
|
bool must_lower = this->depth-- > this->max_depth;
|
|
|
|
|
|
2010-12-27 00:22:38 -08:00
|
|
|
/* Only flatten when beyond the GPU's maximum supported nesting depth. */
|
2016-07-03 17:11:07 +02:00
|
|
|
if (!must_lower && this->min_branch_cost == 0)
|
2010-12-27 00:22:38 -08:00
|
|
|
return visit_continue;
|
|
|
|
|
|
2016-07-03 14:57:20 +02:00
|
|
|
this->found_unsupported_op = false;
|
2016-07-03 17:11:07 +02:00
|
|
|
this->found_expensive_op = false;
|
|
|
|
|
this->then_cost = 0;
|
|
|
|
|
this->else_cost = 0;
|
2016-07-03 14:57:20 +02:00
|
|
|
|
2010-07-19 09:36:43 -07:00
|
|
|
ir_assignment *assign;
|
|
|
|
|
|
|
|
|
|
/* Check that both blocks don't contain anything we can't support. */
|
2016-07-03 17:11:07 +02:00
|
|
|
this->is_then = true;
|
2014-06-24 21:34:05 -07:00
|
|
|
foreach_in_list(ir_instruction, then_ir, &ir->then_instructions) {
|
2016-07-03 15:03:54 +02:00
|
|
|
visit_tree(then_ir, check_ir_node, this);
|
2010-07-19 09:36:43 -07:00
|
|
|
}
|
2016-07-03 17:11:07 +02:00
|
|
|
|
|
|
|
|
this->is_then = false;
|
2014-06-24 21:34:05 -07:00
|
|
|
foreach_in_list(ir_instruction, else_ir, &ir->else_instructions) {
|
2016-07-03 15:03:54 +02:00
|
|
|
visit_tree(else_ir, check_ir_node, this);
|
2010-07-19 09:36:43 -07:00
|
|
|
}
|
2016-07-03 17:11:07 +02:00
|
|
|
|
2016-07-03 14:57:20 +02:00
|
|
|
if (this->found_unsupported_op)
|
|
|
|
|
return visit_continue; /* can't handle inner unsupported opcodes */
|
2010-07-19 09:36:43 -07:00
|
|
|
|
2016-07-03 17:11:07 +02:00
|
|
|
/* Skip if the branch cost is high enough or if there's an expensive op. */
|
|
|
|
|
if (!must_lower &&
|
|
|
|
|
(this->found_expensive_op ||
|
|
|
|
|
MAX2(this->then_cost, this->else_cost) >= this->min_branch_cost))
|
|
|
|
|
return visit_continue;
|
|
|
|
|
|
2011-01-21 14:32:31 -08:00
|
|
|
void *mem_ctx = ralloc_parent(ir);
|
2010-07-19 09:36:43 -07:00
|
|
|
|
2011-08-01 13:55:46 -07:00
|
|
|
/* Store the condition to a variable. Move all of the instructions from
|
|
|
|
|
* the then-clause of the if-statement. Use the condition variable as a
|
|
|
|
|
* condition for all assignments.
|
2010-07-19 09:36:43 -07:00
|
|
|
*/
|
2011-08-01 13:55:46 -07:00
|
|
|
ir_variable *const then_var =
|
|
|
|
|
new(mem_ctx) ir_variable(glsl_type::bool_type,
|
|
|
|
|
"if_to_cond_assign_then",
|
|
|
|
|
ir_var_temporary);
|
|
|
|
|
ir->insert_before(then_var);
|
|
|
|
|
|
|
|
|
|
ir_dereference_variable *then_cond =
|
|
|
|
|
new(mem_ctx) ir_dereference_variable(then_var);
|
|
|
|
|
|
|
|
|
|
assign = new(mem_ctx) ir_assignment(then_cond, ir->condition);
|
2010-07-19 09:36:43 -07:00
|
|
|
ir->insert_before(assign);
|
|
|
|
|
|
2011-08-01 13:55:46 -07:00
|
|
|
move_block_to_cond_assign(mem_ctx, ir, then_cond,
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
&ir->then_instructions,
|
|
|
|
|
this->condition_variables);
|
|
|
|
|
|
|
|
|
|
/* Add the new condition variable to the hash table. This allows us to
|
|
|
|
|
* find this variable when lowering other (enclosing) if-statements.
|
|
|
|
|
*/
|
2016-08-16 22:10:28 +02:00
|
|
|
_mesa_set_add(this->condition_variables, then_var);
|
2011-08-01 13:28:11 -07:00
|
|
|
|
2011-08-01 13:55:46 -07:00
|
|
|
/* If there are instructions in the else-clause, store the inverse of the
|
|
|
|
|
* condition to a variable. Move all of the instructions from the
|
|
|
|
|
* else-clause if the if-statement. Use the (inverse) condition variable
|
|
|
|
|
* as a condition for all assignments.
|
|
|
|
|
*/
|
|
|
|
|
if (!ir->else_instructions.is_empty()) {
|
|
|
|
|
ir_variable *const else_var =
|
|
|
|
|
new(mem_ctx) ir_variable(glsl_type::bool_type,
|
|
|
|
|
"if_to_cond_assign_else",
|
|
|
|
|
ir_var_temporary);
|
|
|
|
|
ir->insert_before(else_var);
|
|
|
|
|
|
|
|
|
|
ir_dereference_variable *else_cond =
|
|
|
|
|
new(mem_ctx) ir_dereference_variable(else_var);
|
|
|
|
|
|
|
|
|
|
ir_rvalue *inverse =
|
|
|
|
|
new(mem_ctx) ir_expression(ir_unop_logic_not,
|
|
|
|
|
then_cond->clone(mem_ctx, NULL));
|
|
|
|
|
|
|
|
|
|
assign = new(mem_ctx) ir_assignment(else_cond, inverse);
|
|
|
|
|
ir->insert_before(assign);
|
|
|
|
|
|
|
|
|
|
move_block_to_cond_assign(mem_ctx, ir, else_cond,
|
glsl: Modify strategy for accumulating conditions when lowering if-statements
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@20) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool ! (var_ref if_to_cond_assign_condition@24) ) (var_ref if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref (var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
Three changes are made to the way if-statements are lowered.
1. Two condition variables, if_to_cond_assign_then and
if_to_cond_assign_else, are created for each if-then-else structure.
The former contains the "positive" condition, and the later contains
the "negative" condtion. This change was implemented in the previous
patch.
2. Each condition variable is added to a hash-table when it is created.
3. When lowering an if-statement, assignments to existing condtion
variables get the current condition anded. This ensures that nested
condition variables are only set to true when the condition variable
for all outer if-statements is also true.
Changes #1 and #3 combine to ensure the correctness of the resulting
code.
4. When a condition assignment is encountered with a condition that is
a dereference of a previously added condition variable, the condition
is not modified.
Change #4 prevents the continuous accumulation of conditions on
assignments.
If the original if-statements were:
if (x) {
if (a && b && c && d && e) {
...
} else {
...
}
} else {
if (g && h && i && j && k) {
...
} else {
...
}
}
The lowered code will be
if_to_cond_assign_then@1 = x;
if_to_cond_assign_then@2 = a && b && c && d && e
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@2 = !if_to_cond_assign_then
&& if_to_cond_assign_then@1;
...
if_to_cond_assign_else@1 = !if_to_cond_assign_then@1;
if_to_cond_assign_then@3 = g && h && i && j;
&& if_to_cond_assign_else@1;
...
if_to_cond_assign_else@3 = !if_to_cond_assign_then
&& if_to_cond_assign_else@1;
...
Depending on how instructions are emitted, there may be an extra
instruction due to the duplication of the '&&
if_to_cond_assign_{then,else}@1' on the nested else conditions. In
addition, this may cause some unnecessary register pressure since in
the simple case (where the nested conditions are not complex) the
nested then-condition variables are live longer than strictly
necessary.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124. Many, but not all, of these
instructions would have also been eliminated by CSE.
Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-01 14:13:10 -07:00
|
|
|
&ir->else_instructions,
|
|
|
|
|
this->condition_variables);
|
|
|
|
|
|
|
|
|
|
/* Add the new condition variable to the hash table. This allows us to
|
|
|
|
|
* find this variable when lowering other (enclosing) if-statements.
|
|
|
|
|
*/
|
2016-08-16 22:10:28 +02:00
|
|
|
_mesa_set_add(this->condition_variables, else_var);
|
2011-08-01 13:55:46 -07:00
|
|
|
}
|
2010-07-19 09:36:43 -07:00
|
|
|
|
|
|
|
|
ir->remove();
|
|
|
|
|
|
|
|
|
|
this->progress = true;
|
|
|
|
|
|
|
|
|
|
return visit_continue;
|
|
|
|
|
}
|