[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