[SPIR-V] DXC generates invalid SPIRV for multiple entry points

[alelenv]

Description
DXC generates invalid SPIRV with following error

fatal error: generated SPIR-V is invalid: In Logical addressing, variables can only allocate a storage buffer pointer if the VariablePointersStorageBuffer capability is declared
%Foo = OpVariable %_ptr_Private__ptr_StorageBuffer_type_StructuredBuffer_v4float Private

Steps to Reproduce
https://godbolt.org/z/hhxdPoaGT

Options used : -spirv -T lib_6_6 -fspv-target-env=vulkan1.3
--->

Actual Behavior
The shader seems legal and generates DXIL

The issue seems to be spirv-opt PrivateToLocal will not handle cases like above post inlining with multiple entry points
If DXC adds "VariablePointersStorageBuffer" capability this should end up working

Erroring out such hard to support cases seems fine as well

Environment

• DXC version libdxcompiler.so: 1.10(dev;1-948629ac); libdxil.so: 1.10
• Host OS : Windows

[Keenuts]

Hi,
Thanks for the report!
Looks like the issue is not related to the resource heaps, but caused by the presence of the static const in front of the StructuredBuffer when used across 2 entrypoints in a library.

The resource heaps in functions like those might cause issues but this is I think more related to #7978. Here is a repro focusing on the resource being used in 2 entrypoints.

https://godbolt.org/z/bTK3drMs1

[Keenuts]

Looking into this a bit.

One bit that should be OK, and works to some extent is:

RWStructuredBuffer<uint> rsc;
static const RWStructuredBuffer<uint> alias = rsc;

[...]
alias[0] = 1;

This works in the basic case, but fails with multiple entrypoints. Seems like the issue in in SPIRV-Tools: legalization should replace alias with rsc, but with multiple entrypoints, it's not done. Not sure why yet but this looks like an issue.

The other issue is:

RWStructuredBuffer<uint> a;
RWStructuredBuffer<uint> b;

RWStructuredBuffer<uint> get(int choice) { return choice ? a : b; }
static const RWStructuredBuffer<uint> alias = get(1);

Looking at DXC, they allow the initialization functions to be quite complex. They don't allow recursion, but allow many loops and arithmetic operations, as long as this can be constexprified.
For SPIR-V, we don't have this, meaning we won't be able to match DXIL behavior unless a heavy investment to allow this kind of constexpr evaluation.

So I think we should investigate into why SPIR-V tools legalization fails in the basic case (alias or a fixed resource), but we might want to emit an error in DXC as soon as the initializer is not another variable to fail gracefuly.