!UPSTREAM: print blorp blit surface formats
glsl: Teach ir_variable_refcount about ir_loop::counter variables.

If an ir_loop has a non-null "counter" field, 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.
!UPSTREAM: glsl: Make hierarchical visitor visit ir_loop::counter.

This will ensure that if an ir_loop contains a non-null "counter"
field, the variable declared in that field will get properly
reparented.

TODO: squash with next.
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.

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, the loop counter wouldn't be 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
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.
glsl: Improve documentation of ir_loop counter/control fields.