Re-design GetAttributeAtVertex

[llvm-beanz]

Is your feature request related to a problem? Please describe.
The current implementation of GetAttributeAtVertex has bugs which are products of the design rather than just the implementation:

• GetAttributeAtVertex() doesn't work on function parameters DirectXShaderCompiler#6220
• Attributes read via GetAttributeAtVertex aren't counted as read in the signature DirectXShaderCompiler#5417
• [SPIR-V][Sema] Requires nointerpolation on GetAttributeAtVertex param #0 DirectXShaderCompiler#6453

Describe the solution you'd like
We need to design a different approach to this feature that doesn't rely on compiler optimization to guarantee correctness.

Describe alternatives you've considered

• Use a proper type qualification for data that may have attributes
• Use a boxed type for parameters that may have attributes

[llvm-beanz]

(cc @Keenuts, @sudonatalie, @tex3d)

I filed this to track our need to spend some time designing an alternate solution at the language level to handle GetAttributeAtVertex.

[Keenuts]

Do you happen to know how the DXIL side is usually implemented? And why we haven't required the input of GetAttributeAtVertex() to be an array of 3?

On the SPIR-V Side, the shader ends up with a array as input. nointerpolate float a : A would give us roughly:

%array_type = OpTypeArray %float 3
%a = OpVariable %array_type Input

So if the HLSL type was an actual array, it would be quite easy to support this feature correctly.

[llvm-beanz]

The DXIL side of this is totally magic (and buggy). We don't actually represent the parameter as anything but the specified source type. The presence of the attributes is implied in DXIL not represented.