[cfe-dev] [RFC] Improved address space conversion semantics for targets and language dialects
Ronan KERYELL via cfe-dev
cfe-dev at lists.llvm.org
Fri Mar 8 11:39:07 PST 2019
>>>>> On Wed, 6 Mar 2019 18:11:39 +0000, Bevin Hansson via cfe-dev <cfe-dev at lists.llvm.org> said:
Bevin> Many address space semantics are locked behind the OpenCL
Bevin> language option, even though those semantics would likely be
Bevin> applicable to non-OpenCL cases as well. This means that, when
Bevin> not using any particular address space-using language
Bevin> dialect, the address space semantics are far too loosely
Bevin> defined. When using address spaces outside of the ones
Bevin> defined in LangAS (the 'target' address spaces), you can
Bevin> convert between any two address spaces explicitly, even
Bevin> though this might not make sense on a particular
Bevin> target. There is no way for a target to define which address
Bevin> spaces are compatible with each other.
Bevin> Technically, this behavior is in accordance with the
Bevin> Embedded-C TR (explicitly converting between all address
Bevin> spaces is allowed, but undefined if they aren't compatible),
Bevin> but I do not believe this behavior is meaningful. If a
Bevin> target's address spaces are disjoint, there is no reason to
Bevin> let a user convert between them, even with a cast.
At least there is some value allowing explicit conversion in general
between address spaces to do some basic type erasure. Otherwise it is
difficult to implement things like C++ std::any or whatever.
Of course at the end you go back to the original address space after a
journey though the type erased address space
AS1 → AS_erased → AS1.
Thank you for having started this discussion. It is time to unify our
efforts through the various users of address spaces.
--
Ronan KERYELL
More information about the cfe-dev
mailing list