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

Adam Strzelecki ono at java.pl
Sat May 3 07:25:40 PDT 2014


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

Agreed. I understand that:
__attribute__((address_space(1)) int *p_1 = ...;
__attribute__((address_space(2)) int *p_2 = p_1;
should be treated as invalid whatever you do.

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

Again. This is clear too.

> For C++, with a non-trivial copy constructor, you'd have to provide a copy constructor for each possible source address space.

Yes, however since there is absolutely NO way to force plain C behavior from C++, it is now impossible to define such constructor.
[1] At least I don't know any way to trigger non-constructor plain C copy on C++ struct/class that will emit proper @llvm.memcpy.

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

Yes this is kind of solution, but it would work ONLY for classes having no own copy constructor, which is pretty limiting.

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

Agreed. I think some explicit way of copying[1] (omitting C++ constructors) would be sufficient for a start.

Regards,
-- 
Adam



More information about the cfe-dev mailing list