<div dir="ltr"><div>Those fuzzing guys are mean...</div><div><br></div><div>This stuff is subtle but I think this is correct.  Assuming you've run it through our CI and everything is good,<br></div><div><br></div><div>Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 27, 2019 at 5:05 AM Juan A. Suarez Romero <<a href="mailto:jasuarez@igalia.com">jasuarez@igalia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When emitting a branch in a block, it does not make sense to continue<br>
processing further instructions, as they will not be reachable.<br>
<br>
This fixes a nasty case with a loop with a branch that both then-part<br>
and else-part exits the loop:<br>
<br>
%1 = OpLabel<br>
     OpLoopMerge %2 %3 None<br>
     OpBranchConditional %false %2 %2<br>
%3 = OpLabel<br>
     OpBranch %1<br>
%2 = OpLabel<br>
    [...]<br>
<br>
We know that block %1 will branch always to block %2, which is the merge<br>
block for the loop. And thus a break is emitted. If we keep continuing<br>
processing further instructions, we will be processing the branch<br>
conditional and thus emitting the proper NIR conditional, which leads to<br>
instructions after the break.<br>
<br>
This fixes dEQP-VK.graphicsfuzz.continue-and-merge.<br>
<br>
CC: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>><br>
---<br>
 src/compiler/spirv/vtn_cfg.c | 1 +<br>
 1 file changed, 1 insertion(+)<br>
<br>
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c<br>
index c32d54e9006..7868eeb60bc 100644<br>
--- a/src/compiler/spirv/vtn_cfg.c<br>
+++ b/src/compiler/spirv/vtn_cfg.c<br>
@@ -916,6 +916,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head *cf_list,<br>
          if (block->branch_type != vtn_branch_type_none) {<br>
             vtn_emit_branch(b, block->branch_type,<br>
                             switch_fall_var, has_switch_break);<br>
+            return;<br>
          }<br>
<br>
          break;<br>
-- <br>
2.20.1<br>
<br>
</blockquote></div>