[0006] Address space overload resolution rules

[llvm-beanz]

Which proposal does this relate to?
0006-Reference Types

Describe the issue or outstanding question.
We need to think about how to handle address spaces in overload resolution. Some specific edge cases to be concerned about:

• Implicit object in member functions, constructors and overloaded operators
• Builtin functions where arguments are references

Additional context
Some relevant discussion occurred in https://github.com/llvm/llvm-project/pull/122103/files

[devshgraphicsprogramming]

IMHO cleanest would be to have separate address space == separate type.

With some leeway for a generic pointer for context you know you can disambiguate later or don't need to disambiguate.

However whenever it would cause you to have to emit lets say the same function twice, or the same struct twice or worse inline a function to legalize the SPIR-V I'd go separate address space == separate type.

You can see the mess of emitting 3 different invisible under the hood invisible OpTypeStruct for a single HLSL struct depending on address space in microsoft/DirectXShaderCompiler#6541