aaron.ballman added a comment. In D151087#4363503 <https://reviews.llvm.org/D151087#4363503>, @ebevhan wrote:
> In D151087#4362059 <https://reviews.llvm.org/D151087#4362059>, @aaron.ballman > wrote: > >> Based on all this, I think we should go with `__addrspace_cast` as a named >> cast and not allow the conversion through `reinterpret_cast` unless going >> to/from a `[u]intptr_t`. > > I think this sounds good. Most of the building blocks for it should already > be in place in the form of OpenCL's addrspace_cast. It would remove > reinterpret_cast's ability to perform safe conversions, though. Could that > affect something else inadvertently? ICS or SCS? > > There are other C++ casts that deal with address spaces today. static_cast > can also do it when converting from a void pointer, for example. Should it > also lose the ability? I think this is another design approach we could consider -- splitting the functionality out between the various C++ named casts. According to the TR, we should know at compile time which address spaces exist and whether space B is a subset of space A or whether they're disjoint. There can be implicit conversions from A to B if A is a subset of B, but it might not be bit-pattern preserving. That's similar to a derived-to-base conversion. `static_cast` can reverse implicit conversions, so it could be used to reverse the A->B conversion. It'd be undefined behavior if the pointer isn't representable in A's address space, but that's also the same as a base-to-derived conversion when the object doesn't have a derived type. For disjoint conversions of A to B, static_cast should fail (and perhaps C-style casts should as well -- there's no meaningful conversion between disjoint address spaces). And then `dynamic_cast` could be used for doing reverse implicit conversions that can detect invalid conversion attempts and throw an exception/return a nullptr. `reinterpret_cast` could then be used for bit-pattern preserving same-sized casts so it remains a bitcast operation. (This idea came via a different WG21 member I was also discussing this topic with.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151087/new/ https://reviews.llvm.org/D151087 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
