David Neto

I'm having trouble parsing this: > However, since it isn't specified that Vin(...) creates new nodes, I think this rule could be interpreted to mean that the node representing the...

ok, so conceptually the confusion is something like this: good case: Vout(prev)-for-x loop { Vin(s1)-for-x s1; ... } // with an edge from Vin(s1)-for-x to Vout(prev)-for-x bad case: Vout(prev)-for-x-is-also-Vin(s1)-for-x loop...

I suggest treating this as editorial; committee work not required.

Yes, it looks that way. Thanks for filing this.

Yes, that does look conservative. An easy way to see it: Start with the first shader, and pull the assignment `x = 1;` to before the loop, and it now...

Regarding > The conservative treatment seems to be a side effect of the fact that the analysis of an expression often produces a value node that depends on CF which...

> Mostly a request for editorial strengthening: add a definition of "uniformity scope" and making uniform control flow be defined with respect to a particular scope. This strengthening could be...

To clarify: `spirv-link` supports combining SPIR-V modules into a single SPIR-V module. (Some parts may have entry points, some might not). But use of spirv-link is all done before presenting...

I've heard requests for shader linking several times over the years in various contexts. It's often an instance of the [XY problem ](https://en.wikipedia.org/wiki/XY_problem) (where someone asks for a particular solution...

This behaviour is expected. The toolchains in the NDK r17c are too old. That NDK is from June 2018. Please update your NDK releases. Recommend closing as wont-fix.