Unstructured control flow

[lifpan]

Will you support unstructured control flow which don't use "OpLoopMerge" and "OpSelectionMerge"?

I'd like to add a member variable for SPIRBlock struct:
uint32_t after_block = 0; // The block literally resides just after current block.

[HansKristian-Work]

I don't really understand the question. SPIRV-Cross can only support the requirements of the Shader programming model, i.e. structured control flow. Please elaborate with a concrete SPIR-V example.

[lifpan]

I'm processing some SPIR-V shader from Apple Metal, which is unstructured control flow. It converts unstructured llvm to unstructured SPIR-V. I want to analyze it's control flow, so I'd like to add new member variable "after_block" to SPIRBlock struct. In this way, I could traverse all blocks in its literal order easily.
I think SPIRV-Cross could add a module to transform unstructured control flow to structured.

[HansKristian-Work]

I see. I does sound more like this is more suited for SPIRV-Tools though. SPIRV-Cross imo, is not the right place to deal with SPIR-V -> SPIR-V transforms. SPIRV-Cross does not support serializing out the structured SPIR-V after performing the transform, so it won't be useful for consuming MSL in Vulkan. Is there a reason why this work must be done in SPIRV-Cross in particular?

[lifpan]

No particular reason. Right, it's more suited for SPIRV-Tools. Would you accept this small change if I push it to git depo? I'd like to make my version of SPIRV parser consistent with depo's.

[HansKristian-Work]

I think you'll get the same effect if you loop over SPIRFunction::blocks. Those are in module declaration order.

[lifpan]

I see. Thanks!

[HansKristian-Work]

Cool. Don't there is anything that should change in SPIRV-Cross right now, so closing. Good luck with the MSL transform!

[billhollings]

@lifpan Interesting workflow. What toolchain are you using to go from MSL to SPIR-V?

[lifpan]

@billhollings I'm not responsible for the translation of MSL->LLVM->SPIR-V. I don't know the detail.