Those fuzzing guys are mean... This stuff is subtle but I think this is correct. Assuming you've run it through our CI and everything is good,
Reviewed-by: Jason Ekstrand <[email protected]> On Wed, Feb 27, 2019 at 5:05 AM Juan A. Suarez Romero <[email protected]> wrote: > When emitting a branch in a block, it does not make sense to continue > processing further instructions, as they will not be reachable. > > This fixes a nasty case with a loop with a branch that both then-part > and else-part exits the loop: > > %1 = OpLabel > OpLoopMerge %2 %3 None > OpBranchConditional %false %2 %2 > %3 = OpLabel > OpBranch %1 > %2 = OpLabel > [...] > > We know that block %1 will branch always to block %2, which is the merge > block for the loop. And thus a break is emitted. If we keep continuing > processing further instructions, we will be processing the branch > conditional and thus emitting the proper NIR conditional, which leads to > instructions after the break. > > This fixes dEQP-VK.graphicsfuzz.continue-and-merge. > > CC: Jason Ekstrand <[email protected]> > --- > src/compiler/spirv/vtn_cfg.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c > index c32d54e9006..7868eeb60bc 100644 > --- a/src/compiler/spirv/vtn_cfg.c > +++ b/src/compiler/spirv/vtn_cfg.c > @@ -916,6 +916,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct > list_head *cf_list, > if (block->branch_type != vtn_branch_type_none) { > vtn_emit_branch(b, block->branch_type, > switch_fall_var, has_switch_break); > + return; > } > > break; > -- > 2.20.1 > >
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
