[PATCH] D102689: [C++4OpenCL] Allow address space conversion in reinterpret_cast

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D102689#2778011 <https://reviews.llvm.org/D102689#2778011>, @rjmccall wrote:

> The C++ standard does not appear to have similar wording.  On the other hand, the C++ standard says that e.g. "The result of the expression `(T) cast-expression` is of type `T`", and similarly for the other casts, which is clearly just wrong if `T` is a reference type; the wording clarifies that the expression is an l-value or x-value if the type is a reference but doesn't remove the reference-ness of the expression type as it must, unless that's done by some other clause at a distance.

It is indeed done by a different clause at a distance:

**[expr.type]**

> 1. If an expression initially has the type “reference to `T`”, the type is adjusted to `T` prior to any further analysis. The expression designates the object or function denoted by the reference, and the expression is an lvalue or an xvalue, depending on the expression.



> 2. If a prvalue initially has the type “cv `T`”, where `T` is a cv-unqualified non-class, non-array type, the type of the expression is adjusted to `T` prior to any further analysis.



In D102689#2778011 <https://reviews.llvm.org/D102689#2778011>, @rjmccall wrote:

> C++ has a very strange feature of allowing qualifiers on class types in particular circumstances, so we might need to be permissive about that, although that's tricky for address spaces because (unlike with `const` or `volatile`) we cannot in fact allocate a temporary in an arbitrary address space.

Right, specifically C++ preserves top-level `const` and `volatile` qualifications on prvalues only if they're of class or array type. If an address-space-qualified temporary makes sense, then I think extending this behavior to address spaces makes sense too:

- For array prvalues, an `AS1 int[3]` should decay to an `AS1 int*`, not to a plain `int*`, because it seems clear the intent is for the array to be created in the given address space.
- For class prvalues, I think it's important that we preserve the address space, because (for example) a function `AS1 MyClass f();` might take a return value slot as an `AS1` pointer, so a prvalue `f()` should retain the address space qualification.

While we can't allocate an address-space-qualified temporary right now, would it be a good idea to prepare for the possibility that we will one day be able to, in some cases? For example, in a system with separate control and data stacks, we might want to put some data on the control stack; in an exotic heterogeneous compute system we might be able to allocate memory in the host and device stack from a single function.  If so, following the C++ rule for all qualifiers might be a good direction. (We'll presumably need to look at the other qualifiers and see if any of them would have problems with this treatment.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102689/new/

https://reviews.llvm.org/D102689