On Thursday, November 19, 2015 02:05:44 PM Kenneth Graunke wrote: > We've apparently always been botching JIP for sequences such as: > > do > cmp.f0.0 ... > (+f0.0) break > ... > if > ... > else > ... > endif > ... > while > > Normally, UIP is supposed to point to the final destination of the jump, > while in nested control flow, JIP is supposed to point to the end of the > current nesting level. It essentially bounces out of the current nested > control flow, to an instruction that has a JIP which bounces out another > level, and so on. > > In the above example, when setting JIP for the BREAK, we call > brw_find_next_block_end(), which begins a search after the BREAK for the > next ENDIF, ELSE, WHILE, or HALT. It ignores the IF and finds the ELSE, > setting JIP there. > > This makes no sense at all. The break is supposed to skip over the > whole if/else/endif block entirely. They have a sibling relationship, > not a nesting relationship. > > This patch fixes brw_find_next_block_end() to track depth as it does > its search, and ignore anything not at depth 0. So when it sees the > IF, it ignores everything until after the ENDIF. That way, it finds > the end of the right block. > > Caught while debugging a tessellation shader - no apparent effect on > Piglit. I did look for actual applications that were affected, and > found that GLBenchmark Manhattan had a BREAK with a bogus JIP. > > Cc: mesa-sta...@lists.freedesktop.org > Signed-off-by: Kenneth Graunke <kenn...@whitecape.org>
I tried pretty hard to produce a Piglit test that showed an actual problem from doing this wrong - and I wasn't able to. It seems it just steps through some extra instructions which do nothing, and is pretty harmless. So I don't think this should actually go to stable after all.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
