On 10/04/2011 10:37 AM, Eric Anholt wrote:
On Mon, 03 Oct 2011 16:34:28 -0700, Ian Romanick<i...@freedesktop.org> wrote:
On 10/03/2011 03:41 PM, Eric Anholt wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 2000180..555d26d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1347,6 +1347,19 @@ fs_visitor::register_coalesce()
interfered = true;
break;
}
+
+ /* The accumulator result appears to get used for the
+ * conditional modifier generation. When negating a UD
+ * value, there is a 33rd bit generated for the sign in the
+ * accumulator value, so now you can't check, for example,
+ * equality with a 32-bit value. See piglit fs-op-neg-uint.
+ */
+ if (scan_inst->conditional_mod&&
+ inst->src[0].negate&&
+ inst->src[0].type == BRW_REGISTER_TYPE_UD) {
+ interfered = true;
+ break;
+ }
}
if (interfered) {
continue;
}
+
+void
+fs_visitor::resolve_ud_negate(fs_reg *reg)
+{
+ if (reg->type != BRW_REGISTER_TYPE_UD ||
+ !reg->negate)
+ return;
+
+ fs_reg temp = fs_reg(this, glsl_type::uint_type);
+ emit(BRW_OPCODE_MOV, temp, *reg);
+ *reg = temp;
+}
I suspect I know the answer, but are we sure that a later optimization
pass won't copy propagate this extra move away?
That's what the hunk in the badly-named copy-propagation pass is about
(and the neg-uint test tested it specifically).
I seemed to recall that there was something like that, but I wanted to
be sure. For the series:
Ian Romanick <ian.d.roman...@intel.com>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
