[clang] [Clang] Allow all address spaces to be converted to the default (PR #112248)

[Alex Voicu via cfe-commits]

AlexVlx wrote:

> > Running into an observable situation where this is a concern means that either you've messed around with (non C/C++) attributes, or are linking in something exciting. Neither of which constitutes valid C/C++, and I'm leaning towards saying shouldn't be allowed to silently work - we probably should refrain from infecting C/C++ with explicit address spaces a la OpenCL. What are you actually running into @jhuber6 where this is a concern? More specifically, you are saying "we want to do X, in C++" -> why?
> 
> I'm trying to port the OpenMP device runtime to just use C/C++, we use a lot of `__local` variables there which this turns into a mess of C-style casts. It also interacts badly with the `this` pointer if you put a class inside of anything with an address space. C/C++ says nothing about address spaces, but these basically act as target specific attributes on certain types.
> 
> This is a case where it's actually harder to do something in C/C++ than OpenCL and I don't want it to be that way. See https://godbolt.org/z/1Gn71qqPT for an example of what I'm talking about.
> 
> TL;DR, every other language allows this and I want to be able to use classes or LDS variables without spamming `(int &)` everywhere.

Well it's harder to do OpenCL in C++ than doing OpenCL in OpenCL is not entirely surprising, is it? I understand you do not want to do it that way, however this allows for what is essentially non-standard C++ to sneakily start "working" as if it were standard C++. Every other language in this case == every other GPU offload language modelled after CUDA/OpenCL, but I don't know if that should mean we can simply drop something in an otherwise standard C++ compilation. This is important because these are typefully significant target specific attributes, with consequential semantics in the AST (for example they contribute to overload resolution). It's also plausibly important for quirky cases such as bit-patterns `nullptr` / `NULL` for different address spaces - as I said, not all AS-casts to generic have to be NOPs. So overall I'm leaning against doing it as is; guarding it under some flavour of `allow-relaxed-address-space-handling` or something that sounds better but is still noisy enough to make it clear there's danger seems preferable, at least to me.

https://github.com/llvm/llvm-project/pull/112248