[cfe-dev] Allow implicit copy constructor between address spaces in C++

[John McCall]

On May 3, 2014, at 6:40 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> It looks correct to reject this.  Pointers to different address spaces can't be used interchangeably - they can require different instructions to load and store, depending on the architecture, and for disjoint address space there may be no mechanism for translating an address from one to the other.
> 
> For C, this is fine because we just emit an llvm.memcpy from one address space to the other[1], which can be turned into a sequence of loads from one address space and stores to the other.
> 
> For C++, with a non-trivial copy constructor, you'd have to provide a copy constructor for each possible source address space.  With a the default copy constructor, you'd have to teach clang that it should be providing a default copy constructor for each possible address space.  I'm not sure this would even be the correct thing to do, because some classes may not support copying between address spaces and so there's a lot of complexity that you'd have to think about before proposing a correct model for the language to support.

It’s worse than that.  The address space propagates through member accesses in the type system, so correct type-checking requires you to be able to overload member functions by the address space of “this” — and not just for regular member functions, but for constructors and destructors, too.

(I think this isn’t actually a problem for OpenCL++ in practice because you typically don’t create or even modify objects in non-local address spaces.)

The simplest solution here is probably to add a special case to the type-checker which permits an address-space mismatch when directly calling a trivial copy constructor or copy-assignment operator.

John.