i965/vec4: Fix dead code elimination for VGRFs of size > 1.
authorKenneth Graunke <kenneth@whitecape.org>
Sat, 14 Jun 2014 10:53:07 +0000 (03:53 -0700)
committerKenneth Graunke <kenneth@whitecape.org>
Sun, 15 Jun 2014 23:51:05 +0000 (16:51 -0700)
When faced with code such as:

    mov vgrf31.0:UD, 960D
    mov vgrf31.1:UD, vgrf30.xxxx:UD

The dead code eliminator didn't consider reg_offsets, so it decided that
the second instruction was writing was writing to the same register as
the first one, and eliminated the first one.  But they're actually
different registers.

This fixes INTEL_DEBUG=shader_time for vertex shaders.  In the above
code, vgrf31.0 represents the offset into the shader_time buffer where
the data should be written, and vgrf31.1 represents the actual time
data.  With a completely undefined offset, results were...unexpected.

I think this is probably one of the few cases (maybe only case) where we
generate multiple MOVs to a large VGRF.  Normally, we just use them as
texturing results; the other SEND-from-GRF uses a size 1 VGRF.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79029
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
src/mesa/drivers/dri/i965/brw_vec4.cpp

index e816b94e608bffb97b6597b37f4f58f1dea02930..ee5be56b7132643881f4ab71a40eb104d149fb7a 100644 (file)
@@ -464,7 +464,8 @@ vec4_visitor::dead_code_eliminate()
          }
 
          if (inst->dst.file == scan_inst->dst.file &&
-             inst->dst.reg == scan_inst->dst.reg) {
+             inst->dst.reg == scan_inst->dst.reg &&
+             inst->dst.reg_offset == scan_inst->dst.reg_offset) {
             int new_writemask = scan_inst->dst.writemask & ~dead_channels;
 
             progress = try_eliminate_instruction(scan_inst, new_writemask, brw) ||