glsl: Fix loop analysis of nested loops.

Previously, when visiting a variable dereference, loop analysis would
only consider its effect on the innermost enclosing loop.  As a
result, when encountering a loop like this:

    for (int i = 0; i < 3; i++) {
      for (int j = 0; j < 3; j++) {
        ...
        i = 2;
      }
    }

it would incorrectly conclude that the outer loop ran three times.

Fixes piglit test "vs-inner-loop-modifies-outer-loop-var.shader_test".
glsl: Fix handling of function calls inside nested loops.

Previously, when visiting an ir_call, loop analysis would only mark
the innermost enclosing loop as containing a call.  As a result, when
encountering a loop like this:

    for (i = 0; i < 3; i++) {
      for (int j = 0; j < 3; j++) {
        foo();
      }
    }

it would incorrectly conclude that the outer loop ran three times.
(This is not certain; if foo() modifies i, then the outer loop might
run more or fewer times).

Fixes piglit test "vs-call-in-nested-loop.shader_test".
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.
glsl: Teach ir_variable_refcount about ir_loop::counter variables.

If an ir_loop has a non-null "counter" field, the variable referred to
by this field is implicitly read and written by the loop.  We need to
account for this in ir_variable_refcount, otherwise there is a danger
we will try to dead-code-eliminate the loop counter variable.

Note: at the moment the dead code elimination bug doesn't occur due to
a bug in ir_hierarchical_visitor: it doesn't visit the "counter"
field, so dead code elimination doesn't treat it as a candidate for
elimination.  But the patch to follow will fix that bug, so we need to
fix ir_variable_refcount first in order to avoid breaking dead code
elimination.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Fix inconsistent assumptions about ir_loop::counter.

The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
ir_loop::counter is non-null, it points to a fresh ir_variable that
should be used as the loop counter (as opposed to an ir_variable that
exists elsewhere in the instruction stream).

However, previous to this patch:

(1) loop_control_visitor did not create a new variable for
    ir_loop::counter; instead it re-used the existing ir_variable.
    This caused the loop counter to be double-incremented (once
    explicitly by the body of the loop, and once implicitly by
    ir_loop::increment).

(2) ir_clone did not clone ir_loop::counter properly, resulting in the
    cloned ir_loop pointing to the source ir_loop's counter.

(3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting
    in the ir_variable being missed by reparenting.

Additionally, most optimization passes (e.g. loop unrolling) assume
that the variable mentioned by ir_loop::counter is not accessed in the
body of the loop (an assumption which (1) violates).

The combination of these factors caused a perfect storm in which the
code worked properly nearly all of the time: for loops that got
unrolled, (1) would introduce a double-increment, but loop unrolling
would fail to notice it (since it assumes that ir_loop::counter is not
accessed in the body of the loop), so it would unroll the loop the
correct number of times.  For loops that didn't get unrolled, (1)
would introduce a double-increment, but then later when the IR was
cloned for linking, (2) would prevent the loop counter from being
cloned properly, so it would look to further analysis stages like an
independent variable (and hence the double-increment would stop
occurring).  At the end of linking, (3) would prevent the loop counter
from being reparented, so it would still belong to the shader object
rather than the linked program object.  Provided that the client
program didn't delete the shader object, the memory would never get
reclaimed, and so the shader would function properly.

However, for loops that didn't get unrolled, if the client program did
delete the shader object, and the memory belonging to the loop counter
got re-used, this could cause a use-after-free bug, leading to a
crash.

This patch fixes loop_control_visitor, ir_clone, and
ir_hierarchical_visitor to treat ir_loop::counter the same way the
back-ends treat it: as a freshly allocated ir_variable that needs to
be visited and cloned independently of other ir_variables.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: In ir_validate, check that ir_loop::counter always refers to a new var.

The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
for some time.  Thanks to the preceding patch, the compiler front-end
no longer breaks this assumption.

This patch adds code to validate the assumption so that if we have
future bugs, we'll be able to catch them earlier.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Improve documentation of ir_loop counter/control fields.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Remove unused field loop_variable_state::loop.

This field was neither initialized nor used.  It was just dead memory.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gen6: Fix multisample resolve blits for luminance/intensity 32F formats.

On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel.  For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.

To work around this problem, sample from the source surface using
R32_FLOAT.  This shouldn't affect rendering correctness, because when
doing these resolve blits, the destination format is R32_FLOAT, so the
channel replication done by L32_FLOAT and I32_FLOAT is unnecessary.

Fixes piglit tests on Sandy Bridge:
- spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float
- spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float

No piglit regressions on Sandy Bridge.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70601

Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
!UPSTREAM: i965/gs: Generalize some error messages for GS.

TODO: find more places to generalize.
TODO: Don't use "VS/GS" terminology.  Use "vec4" terminology, since that will endure longer.
!UPSTREAM: glsl/linker: Fail if linking geometry shader with 0 GEOMETRY_VERTICES_OUT.

ARB_geometry_shader4 spec 2.15.2:
"Linking will also fail [...] if the program object contains objects to form a
geometry shader, and the value of GEOMETRY_VERTICES_OUT_ARB is zero."

Reviewed-by: Paul Berry <stereotype441@gmail.com>

TODO: May not be necessary for GLSL 1.50 style geometry shaders.  Make a test to validate.
!UPSTREAM: Work around bug in AntTweakBar

AntTweakBar tries to use glGetString(GL_EXTENSIONS) when connected to
a core context (it should use glGetStringi()).  Go ahead and allow
this for the time being.
!UPSTREAM: main: check texture target when validating layered framebuffers.

From section 4.4.4 (Framebuffer Completeness) of the GL 3.2 spec:

    If any framebuffer attachment is layered, all populated
    attachments must be layered. Additionally, all populated color
    attachments must be from textures of the same target.

We weren't checking that the attachments were from textures of the
same target.

TODO:
- Make a piglit test for this, and validate it on Nvidia.
!UPSTREAM: print blorp blit surface formats
glsl/loops: consolidate bounded loop handling into a lowering pass.

Previously, all of the back-ends (ir_to_mesa, st_glsl_to_tgsi, and the
i965 fs and vec4 visitors) had nearly identical logic for handling
bounded loops.  This replaces the duplicate logic with an equivalent
lowering pass that is used by all the back-ends.

Note: on i965, there is a slight increase in instruction count.  For
example, a loop like this:

    for (int i = 0; i < 100; i++) {
      total += i;
    }

would previously compile down to this (vec4) native code:

          mov(8)       g4<1>.xD 0D
          mov(8)       g8<1>.xD 0D
    loop:
          cmp.ge.f0(8) null     g8<4;4,1>.xD 100D
    (+f0) break(8)
          add(8)       g5<1>.xD g5<4;4,1>.xD g4<4;4,1>.xD
          add(8)       g8<1>.xD g8<4;4,1>.xD 1D
          add(8)       g4<1>.xD g4<4;4,1>.xD 1D
          while(8) loop

After this patch, the "(+f0) break(8)" turns into:

    (+f0) if(8)
          break(8)
          endif(8)

because the back-end isn't smart enough to recognize that "if
(condition) break;" can be done using a conditional break instruction.
However, it should be relatively easy for a future peephole
optimization to properly optimize this.
glsl/loops: replace loop controls with a normative bound.

This patch replaces the ir_loop fields "from", "to", "increment",
"counter", and "cmp" with a single integer ("normative_bound") that
serves the same purpose.

I've used the name "normative_bound" to emphasize the fact that the
back-end is required to emit code to prevent the loop from running
more than normative_bound times.  (By contrast, an "informative" bound
would be a bound that is informational only).
glsl/loops: Remove unused fields iv_scale and biv from loop_variable class.

These fields were part of some planned optimizations that never
materialized.  Remove them for now to simplify things; if we ever get
round to adding the optimizations that would require them, we can
always re-introduce them.
glsl/loops: Remove unnecessary list walk from loop_control_visitor.

When loop_control_visitor::visit_leave(ir_loop *) is analyzing a loop
terminator that acts on a certain ir_variable, it doesn't need to walk
the list of induction variables to find the loop_variable entry
corresponding to the variable.  It can just look it up in the
loop_variable_state hashtable and verify that the loop_variable entry
represents an induction variable.
glsl/loops: Allocate loop_terminator using new(mem_ctx) syntax.

Patches to follow will introduce code into the loop_terminator
constructor.  Allocating loop_terminator using new(mem_ctx) syntax
will ensure that the constructor runs.
glsl/loops: Move some analysis for loop_controls to loop_analysis.

Previously, the sole responsibility of loop_analysis was to find all
the variables referenced in the loop that are either loop constant or
induction variables, and find all of the simple if statements that
might terminate the loop.  The remainder of the analysis necessary to
determine how many times a loop executed was performed by
loop_controls.

This patch makes loop_analysis also responsible for determining the
number of iterations after which each loop terminator will terminate
the loop, and for figuring out which terminator will terminate the
loop first (I'm calling this the "limiting terminator").

This will allow loop unrolling to make use of information that was
previously only visible from loop_controls, namely the identity of the
limiting terminator.