glsl: In update_max_array_access, fix interface instance check.

In commit f878d20 (glsl: Update ir_variable::max_ifc_array_access
properly), I accidentally used the wrong kind of check to determine
whether the variable being accessed was an interface instance (I used
var->get_interface_type() != NULL when I should have used
var->is_interface_instance()).  As a result, if an unnamed interface
block contained a struct which contained an array,
update_max_array_access() would mistakenly interpret the struct as a
named interface block and try to dereference a null
var->max_ifc_array_access.

This patch corrects the check, fixing the null dereference.

Fixes piglit test interface-block-struct-nesting.

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

Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/vec4: Teach copy propagation about writes to non-GRFs.

During copy propagation, when we encounter an instruction that writes
to register R, we clear out any record of other registers that
previously contained copies of R, since after the write they will
contain the old value of R.

Previously, we only did this for GRFs (since this pass occurs before
register allocation, input ATTRs don't count as GRFs).  As a result,
an instruction stream that moved from an ATTR to a GRF, and then
overwrote the ATTR, might get incorrectly optimized.

In this past this hasn't really been a problem because the only time
we wrote to ATTRs was during vertex attribute fixup, and we never had
a reason to save the old value of the ATTR in a GRF.

However, a future patch will introduce a geometry shader workaround
which re-orders input vertices before executing the body of a geometry
shader--this workaround will produce code like the following:

    A mov tmp, ATTR0
    B mov ATTR0, ATTR1
    C mov ATTR1, ATTR2
    D mov ATTR2, tmp

Without this patch, copy propagation would incorrectly conclude that
after instruction B, tmp still contained a copy of ATTR0, so it would
"optimize" this to:

    B mov ATTR0, ATTR1
    C mov ATTR1, ATTR2
    D mov ATTR2, ATTR0

Which is clearly incorrect.

The solution is to have copy propagation consider writes to non-GRFs
the same way as writes to GRFs--in either case, the write invalidates
previous copies.
i965/vec4_scheduler: Account for WAW deps between HW_REGs

The vec4 instruction scheduler wasn't accounting for write-after-write
dependencies between fixed hardware registers.  As a result, an
instruction stream that contained a sequence of writes to fixed
hardware registers might get scheduled incorrectly.

In the past this hasn't really been a problem because the only time we
wrote to fixed hardware registers was during vertex attribute fixup,
and these could safely occur in any order.

However, a future patch will introduce a geometry shader workaround
which re-orders input vertices before executing the body of a geometry
shader--this workaround will produce code like the following:

    A mov tmp1 g2
    B mov tmp2 g6
    C mov g2   g18
    D mov g6   g22
    E mov g18  g10
    F mov g22  g14
    G mov g10  tmp1
    H mov g14  tmp2

(where the g's represent fixed hardware registers and the tmps
represent GRFs allocated by the register allocator).

This can't occur in any order; H has a write-after-read dependency on
F (H may not safely write to g14 until after F has read from it).

However, since instruction scheduling operates conservatively with
respect to fixed hardware registers (it regards all fixed hardware
registers as a single unit rather than distinguishing between them),
it sees the above instruction stream as:

    A mov tmp1 g??
    B mov tmp2 g??
    C mov g??  g??
    D mov g??  g??
    E mov g??  g??
    F mov g??  g??
    G mov g??  tmp1
    H mov g??  tmp2

And so it considers G to have a write-after-read dependency on F,
rather than H.  As a result, H may wind up getting scheduled before F,
leading to incorrect execution.

The solution is to consider H to have a write-after-write dependency
on G.  This ensures that H won't get scheduled before F, because of
G's dependency on F.

In the long run we may want to consider modifying instruction
scheduling to distinguish between fixed hardware registers, but that's
a performance concern rather than a correctness concern.  Adding the
write-after-write dependency checking for fixed hardware registers
restores correctness.
i965/gs: Reorder triangle strip vertices on Ivy Bridge.

When rendering a triangle strip or triangle strip with adjacency, Ivy
Bridge doesn't order the input vertices of odd numbered triangles in
the way OpenGL requires.  We work around this by using the primitive
ID to detect which triangles are odd numbered, and rearrange the order
of vertices during the geometry shader prolog.

A problem with consulting the primitive ID is that if either primitive
restart or instanced rendering is in use, triangles may have opposite
parity relative to the entire draw call vs. relative to the strip.
Unfortunately there's no easy way around this.  Fortunately, geometry
shaders that truly rely on the proper ordering of vertices within a
triangle strip are likely to be rare, so I think we can live with the
order being wrong when primitive restart or instanced rendering is in
use.

Fixes the following piglit tests on Ivy Bridge:

- glsl-1.50-geometry-primitive-types GL_TRIANGLE_STRIP

- glsl-1.50-geometry-primitive-types GL_TRIANGLE_STRIP_ADJACENCY

- glsl-1.50-geometry-tri-strip-ordering-with-prim-restart
  GL_TRIANGLE_STRIP other

- glsl-1.50-geometry-tri-strip-ordering-with-prim-restart
  GL_TRIANGLE_STRIP_ADJACENCY other