On Mon Sep 18 20:09:45 2023 +0000, Conor McCarthy wrote:
I think the backend should reject shaders with instructions outside blocks, except perhaps `nop`. A valid vsir shader should also contain no instructions outside blocks. Validating that in TPF is too complicated, but this touches on an issue which will arise in DXIL when branch and switch instructions are added. Using the same vsir instructions for both SM4/5 and SM6 shaders would require handling the SM4/5 structured control flow instructions in a normalisation stage, which would perform all validations.
Hmmm, in my case the VSIR shader passed to the SPIR-V backend is valid and has no instructions outside a block. However, when dealing with unconditional control flow (e.g. a `return` or `break`) inside a loop, the SPIR-V generator outputs, say, `OpReturn`, which terminates the current block, but then goes on outputting any other dead code which appears after that `return` or `break` without opening another block. The generated SPIR-V is thus illegal.
I changed it so that after `OpReturn` another dummy SPIR-V block is began and the generated SPIR-V is valid. That's a problem with the SPIR-V code generation, not with VSIR.