glsl: In loop analysis, handle unconditional second assignment.

Previously, loop analysis would set
this->conditional_or_nested_assignment based on the most recently
visited assignment to the variable.  As a result, if a vaiable was
assigned to more than once in a loop, the flag might be set
incorrectly.  For example, in a loop like this:

    int x;
    for (int i = 0; i < 3; i++) {
      if (i == 0)
        x = 10;
      ...
      x = 20;
      ...
    }

loop analysis would have incorrectly concluded that all assignments to
x were unconditional.

In practice this was a benign bug, because
conditional_or_nested_assignment is only used to disqualify variables
from being considered as loop induction variables or loop constant
variables, and having multiple assignments also disqualifies a
variable from being considered as either of those things.

Still, we should get the analysis correct to avoid future confusion.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This commit is contained in:
Paul Berry 2013-11-28 11:11:17 -08:00
parent cb38a0dc0a
commit 97d8b77054

View file

@ -52,9 +52,10 @@ loop_variable::record_reference(bool in_assignee,
if (in_assignee) {
assert(current_assignment != NULL);
this->conditional_or_nested_assignment =
in_conditional_code_or_nested_loop
|| current_assignment->condition != NULL;
if (in_conditional_code_or_nested_loop ||
current_assignment->condition != NULL) {
this->conditional_or_nested_assignment = true;
}
if (this->first_assignment == NULL) {
assert(this->num_assignments == 0);