This is a very good introduction to the inherent difficulty that comes from trying to do SIMT execution / whole program vectorization while at the same time giving programmers the power of certain optimization tricks that punch through the SIMT abstraction and expose the underlying vector architecture (via subgroup/wave operations).
The title is somewhat misleading as this trouble isn't specific to SPIR-V. It is inherent to the field, and DXIL has the same problem. (Arguably it's worse there because Microsoft tends to be quite bad at properly specifying semantics of DXIL and DirectX more generally.)
This grew out from a much rantier (and worse) version of this article, which talked about the hurdles I faced when considering SPIR-V codegen for our research compiler (Thorin).
For a while I wanted to rewrite it, and ultimately to properly discuss what I wanted to discuss, I had to write something introductory in a much broader sense. So it sort of organically grew from there, and that's why the title is now a bit weird, but I plan for the rest of the series to continue with SPIR-V as some sort of central reference point.
It's fair to say DXIL suffers from this class of troubles too, there's a series themaister where he describes the awfulness of the story over there, but I don't work with DX and I wanted to make as few comments on that as possible to avoid saying something wrong and unverified.
The title is somewhat misleading as this trouble isn't specific to SPIR-V. It is inherent to the field, and DXIL has the same problem. (Arguably it's worse there because Microsoft tends to be quite bad at properly specifying semantics of DXIL and DirectX more generally.)