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

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D102689#2778072 <https://reviews.llvm.org/D102689#2778072>, @rsmith wrote:

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

Ah, thank you.

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

Hmm.  That's an interesting question, because while I can see how it's an interesting thing to be able to express, it might also lead to otherwise-unnecessary template errors, e.g. if a template type argument is inferred to be `__global MyClass`.  On the other hand, that kind of inference can easily lead to other problems with e.g. locals or fields; making it work in slightly more cases isn't necessarily worthwhile.

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

Hmm, okay, I cede the point.  I have some concerns here (C compatibility and addressability), but we don't have to design AS-qualified return values right now.  I agree that we should be stripping qualifiers except on class and array types.

I believe array types are actually ruled out for casts because there are no conversions to array type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102689