[NNNN] Add proposal for HLSL ConstantBuffer<T>

[s-perron]

This proposal details the implementation of the ConstantBuffer<T>
resource type in Clang and LLVM for HLSL.

Unlike the legacy cbuffer, ConstantBuffer<T> behaves as a standard
type, supporting instantiation, arrays, function parameters, and
assignments. It acts as a drop-in replacement for T via an implicit
conversion operator to const T &. The proposal details the Sema member
lookup interception required and the corresponding CodeGen which targets
the appropriate constant address spaces via resource intrinsics.

[s-perron]

@hekota @bogner @llvm-beanz Hey, here is a draft design for ConstantBuffer<T>. Let me know if you have other ideas or reason this will not work.

I still have to figure out the implicit conversion to T. @spall's work to remove the constructors puts that part in flux.

[hekota]

Looks good, I just wonder whether we need to add the new llvm intrinsic.

We are also going to need to decide if we are going to be supporting resources inside T. DXC seems to support it unless ConstantBuffer<T> is in an array: https://godbolt.org/z/11dTdhzh1

[s-perron]

We are also going to need to decide if we are going to be supporting resources inside T. DXC seems to support it unless ConstantBuffer<T> is in an array: https://godbolt.org/z/11dTdhzh1

That is an awkward one. It never worked for SPIR-V: https://godbolt.org/z/Mqvq4cd6Y.

I would like to disallow it, but we can talk about this more. I'll update the proposal to disallows resources in ConstantBuffers, and then we can have a discussion in the appropriate meeting.

[Keenuts]

What about methods? Should we start enforcing those have a const this?
This somehow is accepted but should IMO not: https://godbolt.org/z/avE8zTKb7

[s-perron]

As I wrote the implementation, your example would be rejected because the member expression would add a cast to const hlsl_constant& T. Since the call to foo is not const it will create an error.

However that is a good example that I need to add. If DXC allowed call to non-const member function, should we allow them too? At what point do we issue an error? Note that your example fails when generating DXIL. I'm not sure why it works for spir-v. We probably have a bad optimization removing the invalid store because the spir-v is invalid.

[Keenuts]

I think we had a couple issues open in DXC for this weirdness,IMO the fact dxc allows this is an oversight, and we should not support this. Maybe something we can specify in hlsl 202x

[s-perron]

I left this as a open question. We should get more people to chime in on. With a good compiler error it might not be too hard for devs to add const where needed if we do require const.

[hekota]

I would like to disallow it, but we can talk about this more. I'll update the proposal to disallows resources in ConstantBuffers, and then we can have a discussion in the appropriate meeting.

I would also be in favor of disallowing resources in ConstantBuffer<T>, and I believe @tex3d mentioned that some time ago as well.

[tex3d]

I would like to disallow it, but we can talk about this more. I'll update the proposal to disallows resources in ConstantBuffers, and then we can have a discussion in the appropriate meeting.

I would also be in favor of disallowing resources in ConstantBuffer<T>, and I believe @tex3d mentioned that some time ago as well.

You definitely weren't ever supposed to be allowed to put a resource in T for ConstantBuffer<T>. I don't know how that was allowed in DXC for a non-array decl, but it's definitely a bug.