Open VyacheslavLevytskyy opened 1 day ago
Hi! Thanks for the repro!
This CFG is irreducible if I'm correct. Thus the topological sort is not possible to determine, and it hangs because it cannot decide what node to start with in the loop.
For DXC/HLSL, we had a simple way to handle that: assert(0 && 'CFG is irreducible')
.
Are irreducible CFG something common in OpenCL?
Hi! Thanks for the repro!
This CFG is irreducible if I'm correct. Thus the topological sort is not possible to determine, and it hangs because it cannot decide what node to start with in the loop.
For DXC/HLSL, we had a simple way to handle that:
assert(0 && 'CFG is irreducible')
. Are irreducible CFG something common in OpenCL?
Yes, I understand that CFG is not a normal or expected one. It's not common in OpenCL as well.
Probably it's better to don't try to sort blocks in that case that to fire an error though. IMO it's better to let common llvm passes to do their work, eliminating unreachable BB's or anything related, but sorting of blocks inside of SPIR-V Backend looks more like a best effort than a precondition to proceed with translation further. If this is indeed a precondition for some further steps, an error can be fired later, at the beginning of the step that requires sorted blocks to succeed. What do you think?
It looks like I may be able to use a mix of LowerSwitchPass
and FixIrreducible
before handling structurizing/sorting, but I agree, an error is better than the crash.
On another bit, It looks like it is valid to generate a SPIR-V module with an irreducible CFG for OpenCL SPIR-V, so I shall make sure the sortBlock method can handle that.
The following reproducer causes
sortBlocks()
to loop without ending:CC: @Keenuts