[202y] Propose adding C++11-style constructors

[llvm-beanz]

This proposal adds user-defined constructors and destructors to HLSL and defines how they should interact with semantics and global initialization. The intent is to align with C++11.

This proposal was originally proposed as #5, however it didn't merge before the repository was moved from private to public, and it got stranded in GitHub's tooling and closed.

[Keenuts]

Hello!

As I was working on input/output/global/private variable using address spaces (to convert this to SPIR-V storage classes), I reached a bit of a question:

Do you have a plan on how to handle ctor/dtor overload resolution depending on this address space? Or can we safely assume the address_space clang attribute will always be forbidden in HLSL for Ctor/Dtor overloading? (Might be useful to keep it for variable declaration for inline SPIR-V)

Example:

struct S {
    S(int value) : member(value) { }
    /* implicit: S(int value) __attribute__((address_space(10))) : member(value) { } */
    int member;
};

static S s_global(23); // AS=10, SC=Private

[numthreads(1, 1, 1)]
void main() {
    S s_local(24) /* AS=0, SC=Function */;
}

Today, OpenCL deals with this with an addrspacecast before passing this, and always calls the default address-space constructor.
If we go this way for our backend, we'll have to legalize the code to fixup all pointers storage classes (since s_global would be Private and not Function).

In my initial plan, I wanted to instantiate one version of the ctor for each used address-space. But this assumes the address_space Clang attribute is forbidden and that the user can not define 2 constructors depending on this' storage class.

[llvm-beanz]

This problem is bigger than just constructors. The same problem occurs for any non-static member function. HLSL 2021 does not allow overloading functions based on the implicit object parameter (constness or address space). That likely does need to change in the future. That's out of the scope of this PR.

WRT your plans for upstream LLVM, I think that we likely need to do what OpenCL does in order to maintain source compatibility for HLSL 202x and earlier. We could consider changing this for 202y, but I don't want to rule out the possibility of supporting overloading by implicit object address space especially as we look to future C++ features like deducing-this, where we may want to allow users a lot more flexibility.