================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
