[PATCH 2/3] Implicit address space conversion on POD assign

[Adam Strzelecki]

Richard wrote:
> I think you're right that using POD here is a mistake, but I don't really think that trivial and standard layout are the right things to check. Instead, I think the rule should be something like: if you cannot initialize an X from a Y, and dropping the address space from Y allows the initialization to succeed in such a way that it only invokes trivial copy/move constructors, then the initialization is permitted, and is performed by first copying Y into X's address space, then calling the trivial constructor (the latter copy should always be elided in practice).

This sounds like a best idea, but what would be consequences of Vtable pointer living in different address space if we allow non-PODs?

I think it would be best to somehow have feed ResolveConstructorOverload with "template" default copy constructor accepting any address space in TryConstructorInitialization after we tried normal constructors (2nd case of C++11 [over.match.list]p1).

So when you define your own constructor for specific address space, you can still chain call to default constructor that does copying for you, then you just make some fixes afterwards in specific constructor.

But this would require CXXRecordDecl modding adding sthing like SMF_AnyAddressSpaceDefaultConstructorTemplate.

Alp wrote:
> So if Adam's C++ OpenCL language mode gets added to clang you can implement the rest of that spec as a library on GitHub without further changes to clang?

For SyCL we need to have dual target issue, because kernel lambdas need to go to SPIR target and wrappers to normal host target.

Have you seen?
https://bitbucket.org/multicoreware/cppamp-driver-ng/wiki/Home

They compile C++ code twice using wrapper script. When compiling to host target they turn all lambdas into symbols, erasing their code (using Clang plugin). On GPU pass they promote lambdas to global functions and erase any other code, then wrap BC into object file.

This is similar what OpenMP does for their blocks.

It is done on using plugins & wrapper scripts rather than modding Clang directly.

This was inspiration for my patches as cppamp's SPIR doesn't work, at least not for Intel OpenCL RT, because we need LLVM BC entries describing kernels. They use also depreciated C LLVM backend to generate OpenCL out of C++, this works for NVIDIA OpenCL, but C backend is known to be buggy.

IMHO it would be great if such logic was embedded in Clang driver, so it can issue 2nd cc1 call that emits LLVM BC (SPIR), PTX or NVIDIA SASS then wrap this into 2nd object file containing global symbols pointing to kernel code start and kernel code size.

This can be as generic as possible so together with AMP, CUDA or SyCL API headers and runtime Clang driver can compile for all of these.

Regards,
-- 
Adam