We should be able to recover the appropriate type from the [element type of our target extension type (https://llvm.org/docs/DirectX/DXILResources.html#buffers) during DXILResourceAnalysis. However, because of opaque pointers, the bitcast isn't really representable in modern LLVM. We'll need to find a way to pass the necessary information along until the DXIL bitcode writer can apply types to the pointers.
This will likely be done as part of #91366 but I'll leave this here as a check that we leave the right global symbol around when we emit metadata from that intrinsic.
In DXIL, the resource metadata includes a ["Pointer to a global constant symbol with the original shape of resource and element type."(https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#metadata-resource-records). In a library shader, this is a global of
%dx.types.Handle
type that is bitcast in the metadata to a type based on the resource's template parameter:We should be able to recover the appropriate type from the [element type of our target extension type (https://llvm.org/docs/DirectX/DXILResources.html#buffers) during DXILResourceAnalysis. However, because of opaque pointers, the bitcast isn't really representable in modern LLVM. We'll need to find a way to pass the necessary information along until the DXIL bitcode writer can apply types to the pointers.