[PATCH] Support for address space casting in order to map these on the new 'addrspacecast' IR instruction

[Michele Scandale]

================
Comment at: lib/CodeGen/CGExprScalar.cpp:1304
@@ +1303,3 @@
+    unsigned SrcAS = Src->getType()->getPointerAddressSpace();
+    if (Ty->isPtrOrPtrVectorTy() && Ty->getPointerAddressSpace() != SrcAS) {
+      llvm::Type *IntTy = CGF.CGM.getDataLayout().getIntPtrType(Src->getType());
----------------
David Tweed wrote:
> I'm not very experienced in this part of the codebase: by what paths would we now end up with a CK_BitCast that's actually an address space cast (that hasn't be actually generated as an CK_AddressSpaceConversion by the front end)?
This is because of the C++ reinterpret_cast semantic: this kind of cast should not change the value, except for truncation or zero extension. A reinterpret_cast that change the address space cannot be mapped to 'addrspacecast' IR instruction because there is no guarantee that the value will be preserved.

With respect to the previous version of the patch, this new version do not break the semantic concept of CK_BitCast. A reinterpret_cast is a CK_BitCast, while  a static_cast involving an address space change are a CK_AddressSpaceConversion.

CStyle cast expressions involving an address space change are a CK_AddressSpaceConversion too.

================
Comment at: test/CodeGenCUDA/address-space-conversion.cu:16
@@ +15,3 @@
+     ((unsigned int *)x)[i] = 0;
+		// CHECK: addrspacecast
+   }
----------------
David Tweed wrote:
> Probably unnecessary paranoia, but if the compiler decides (for some reason) to unroll this loop might you get multiple addrspacecast nodes, in which case  shouldn't the next check have a function name CHECK just in case.
Perfectly fine. I'll fix this.


http://llvm-reviews.chandlerc.com/D2241