Add a spirv-opt pass to add NonWritable to top-level structs when all members are NonWritable

[Tobski]

A quirk of DXC that went unnoticed for years is that instead of decorating the top-level of a buffer as NonWritable, it decorates all members of the buffer. While this is legal, it wasn't noticed during bring up of VK_EXT_descriptor_heap, and a key part of how the mapping APIs in that extension works is making use of this decoration.

A DXC issue has been raised to modify DXC to adjust for this, but for existing shaders it could be useful to be able to do a quick fixup pass, without needing to regenerate all of the shaders.

This issue is a request to at least consider adding a pass to do this to spirv-opt.

[s-perron]

I'd be open to a fix-up pass. We could run it from DXC too if modifying the codegen is too intrusive. Let me know when a PR is open and I can review it.

[Wint3rNight]

I'd like to take a shot at this.

A few things I'd rather settle before writing:

1. If a member is itself a struct whose own members are all NonWritable, should that member count as NonWritable for this purpose, or should the pass only look at direct members?
2. Once the top-level decoration is added, should the per-member NonWritable decorations be removed, or left in place?
3. For a struct with no members skip it, or treat it as vacuously all-NonWritable?
4. Should this cover OpUntypedVariableKHR as well as OpVariable?
5. Should arrays of structs be handled, or just structs directly?

My instinct is conservative on all of them direct members only, leave the member decorations alone, skip empty structs, OpVariable only.

[Tobski]

I'd like to take a shot at this.

Awesome! Thanks!

A few things I'd rather settle before writing:

1. If a member is itself a struct whose own members are all NonWritable, should that member count as NonWritable for this purpose, or should the pass only look at direct members?

This prompted me to go look what DXC actually did, and it turns out that it doesn't decorate structure members, or their members, with NonReadable. This is very much a DXC bug, and I'll add it to the pile. Given this pass is supposed to fixup DXC shaders, I think the answer is to ignore struct members altogether, or at least have the option to ignore them.

2. Once the top-level decoration is added, should the per-member NonWritable decorations be removed, or left in place?

For the sake of brevity, I think removing them would make sense.

3. For a struct with no members skip it, or treat it as vacuously all-NonWritable?

I'd skip it; there's no way to disambiguate this, but it should be safe to ignore given the lack of members as it won't be accessed.

4. Should this cover OpUntypedVariableKHR as well as OpVariable?

It should cover both; if there's a mismatch later in an untyped access, spirv-val should catch that, and it should be a separate issue to try to patch that up (if it's ever needed).

5. Should arrays of structs be handled, or just structs directly?

Just structs directly is fine.

My instinct is conservative on all of them direct members only, leave the member decorations alone, skip empty structs, OpVariable only.

[Wint3rNight]

Thanks! Updated the PR.