[cfe-dev] [RFC] Improved address space conversion semantics for targets and language dialects

[Anastasia Stulova via cfe-dev]

> 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.


I am not sure erasing address space information in the example of

std::any is a good idea as it seems it might violate type safety.


I haven't looked into details yet, perhaps I should. How does it currently

work with other qualifiers btw? In the meantime if you have any code

example where you find removing the address space useful for the case

you have highlighted or any similar one, it would be valuable input for this

discussion.


Thanks!

Anastasia


________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Ronan KERYELL via cfe-dev <cfe-dev at lists.llvm.org>
Sent: 08 March 2019 19:39
To: Bevin Hansson via cfe-dev
Subject: Re: [cfe-dev] [RFC] Improved address space conversion semantics for targets and language dialects

>>>>> 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
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190312/d597d2d5/attachment.html>