PRs #2790 and #2842 were done to fix a problem: stop inlining an OpKill into a loop's continue construct.

Unfortunately, these changes are now causing size regressions for real shaders that do not call functions with OpKill from a continue construct.

Case in point: the attached SPIR-V shader previously optimized to 940 bytes, now optimizes to 1148, an increase in file size of 20% and nearly 100% increase in function size.

I understand that @s-perron attempted to only "fix" problematic shaders but wasn't able to. Unfortunately, a solution was devised that caused all shaders with OpKill to regress in optimized size.

I propose a possible solution: create an analysis which determines if a shader contains a call to a function containing an OpKill from a continue construct. If it does, WrapOpKill and Inlining behave as they do now. If it does not, WrapOpKill returns without wrapping anything and Inlining performs without worrying about OpKill.

The analysis would be run at the beginning of both WrapOpKill and Inlining passes. There might even be a way to preserve the analysis from WrapOpKill to Inlining.

While, admittedly, the increase in size will be less dramatic for larger shaders, the case that this fix is guarding against is so rare, any penalty incurred by non-problematic shaders is difficult to justify.