In theory we might have incorrectly NOP'd instructions that write the
flag, but where that flag value isn't used, and yet the instruction
either writes the accumulator or has side effects.
I don't believe any such instructions exist, so this is mostly a
code cleanup.
Curro pointed out that FS_OPCODE_FB_WRITE has a null destination and
actually writes the flag on Gen4-5 to dynamically decide whether to
write some payload data. The hunk removed in this patch might have
NOP'd it, except that we don't actually mark flags_written() in the
IR, so it doesn't think the flag is touched at all. That's sketchy,
but it means it wouldn't hit this today (though there are likely other
problems!).
v2: Properly replace the inst->regs_written() check in the second
hunk with the flag being live (mistake caught by Curro).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
}
}
- if (inst->dst.is_null() && inst->flags_written()) {
- if (!(flag_live[0] & inst->flags_written())) {
- inst->opcode = BRW_OPCODE_NOP;
- progress = true;
- }
- }
-
if (inst->dst.is_null() &&
!inst->is_control_flow() &&
!inst->has_side_effects() &&
- !inst->flags_written() &&
+ !(flag_live[0] & inst->flags_written()) &&
!inst->writes_accumulator) {
inst->opcode = BRW_OPCODE_NOP;
progress = true;