[SPIRV] Invalid OpCompositeConstruct when aggregate-initializing struct with resource member

[bob80905]

When compiling HLSL that uses brace initialization to construct a struct containing a resource member, DXC's SPIRV backend generates invalid SPIR-V:

fatal error: generated SPIR-V is invalid: Expected Constituent type to be equal to the corresponding member type of Result Type struct %15 = OpCompositeConstruct %ResHolder_0 %Out

Repro:

RWByteAddressBuffer Out : register(u0);

struct ResHolder { RWByteAddressBuffer buf; };

[numthreads(1,1,1)] 
void main() {  
ResHolder h = {Out};
  h.buf.Store(0, 42); 
}

Command:

dxc.exe -spirv -fspv-target-env=vulkan1.3 -T cs_6_0 -Fo out.spv repro.hlsl

DXC DXIL compiles and runs this correctly. DXC version: main (built from source).

[SteveUrquhart]

The SPIR-V Emitter has always emitted technically-invalid pre-legalization SPIR-V for brace-initialized structs that contain resource handles such as buf shown here. Beginning with #7530, dxc began to use an aggregate-level OpCopyLogical to reconstruct values. This aggregate-level OpCopyConstruct is opaque to scalar replacement, meaning that it did not get replaced anymore, the technically-invalid OpCompositeConstruct persists, and we fail validation as shown.

We believe the best solution is to extend the simplification pass in the optimizer to lower an aggregate-level OpCopyLogical to per-field conversions whenever the source is anOpCompositeConstruct. Meanwhile, fields that genuinely require a layout conversion keep their own per-field OpCopyLogical.

We'll open a PR in SPIRV-Tools with this change. One point of coordination: this change does a better job of optimizing vk.buffer-pointer.initlist.hlsl, but the test is CHECKing for operations we've now eliminated. So we'll create a DXC PR with the test bump, and that PR should not merge until DXC is pointing to the updated SPIRV-Tools.

[SteveUrquhart]

I created KhronosGroup/SPIRV-Tools#6746 and the simplified dxc test can be found in #8541