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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
