On 01/20/2015 01:31 AM, Matt Turner wrote:
> @@ -73,10 +72,14 @@ opt_cmod_propagation_local(fs_visitor *v, bblock_t *block)
> scan_inst->dst.reg == inst->src[0].reg &&
> scan_inst->dst.reg_offset == inst->src[0].reg_offset &&
> !scan_inst->is_partial_write()) {
> + enum brw_conditional_mod cond =
> + inst->src[0].negate ? brw_invert_cmod(inst->conditional_mod)
> + : inst->conditional_mod;
> +
> if (scan_inst->can_do_cmod() &&
> ((!read_flag && scan_inst->conditional_mod ==
> BRW_CONDITIONAL_NONE) ||
> - scan_inst->conditional_mod == inst->conditional_mod)) {
> - scan_inst->conditional_mod = inst->conditional_mod;
> + scan_inst->conditional_mod == cond)) {
> + scan_inst->conditional_mod = cond;
I've been adding support for AND.nz here, and a question came up. Does
this work correctly if scan_inst is a CMP and the result register is
used elsewhere? Won't this turn
cmp.l.f0(8) g3<1>D g3<8,8,1>F g4<8,8,1>F
mov.z.f0(8) null g3<8,8,1>D
and(8) g8<1>F g3<8,8,1>UW 0x3f800000
into
cmp.ge.f0(8) g3<1>D g3<8,8,1>F g4<8,8,1>F
and(8) g8<1>F g3<8,8,1>UW 0x3f800000
For AND, we generate a lot of and.z for ir_unop_not in
fs_visitor::emit_bool_to_cond_code. I want to do the same cmod
inversion for that, but it doesn't seem safe. I think I have another
way to deal with this for ir_unop_not, but either I don't really
understand this code or there's already a bug here.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
