[clang] [clang][CodeGen] Add query for a target's flat address space (PR #95728)

[Alex Voicu via cfe-commits]

================
@@ -1764,6 +1764,13 @@ class TargetInfo : public TransferrableTargetInfo,
     return 0;
   }
 
+  /// \returns Target specific flat ptr address space; a flat ptr is a ptr that
+  /// can be casted to / from all other target address spaces. If the target
+  /// exposes no such address space / does not care, we return 0.
----------------
AlexVlx wrote:

> Some targets won't even have a flat address space. But that's fine, because in these specific uses the address space's underlying range/representation/meaning/whatever is completely irrelevant, all that matters is the GlobalObject (GlobalValue?) you get once you strip away an addrspacecasts. So I object to this on several grounds:
> 
> 1. A flat address space may not exist
> 2. These uses don't care about the address space beyond being consistent across files
> 3. The existence of this API invites people to start using it for other things, and relying on properties of it that you've documented as being true which I don't think we want to be guaranteeing
> 
> If you really object to the arbitrary address space in use, I would rather see the special arrays be made overloaded/polymorphic instead so that the addrspacecasts can be avoided entirely .

@jrtc27 this is not purely bespoke for the special arrays (sadly). The core issue is the prevalent, unguarded/unassuming use of AS 0.  Since targets are not really bound to do anything special with 0 (there are no words anywhere saying 0 has any specific properties), problematic / invalid situations arise. This leads to a perpetual game of whack-a-mole as e.g. one brings up a more general purpose language, which is not quite ideal.

Strictly regarding the special purpose arrays, I object to the arbitrary address space because it actually breaks targets as things stand today, for example: SPIR-V uses 0 for private, if we just use 0 we end up trying to generate invalid SPIR-V that casts from global (CrossWorkgroup) to private (Function) when populating them. Yes we can then go and add special handling just for the special arrays etc. in the SPIR-V BE/the downstream Translator, but that seems less than ideal to me.

I'd like to address (1) and (3) (I did worry about those, but we have an interface that returns a vtbl ptr address space, and it was not clear why 0, which on some targets points to a limited visibility/capacity/private/unambiguously non-global private AS, would be valid for a vtable) - instead of unconditionally returning an integer, we could return an `optional`, with the default being to return `std::nullopt`. This'd constrain to uses to folks who know what they want, and why they want it, as opposed to trivial drop-in replacement.

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