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

David Tweed david.tweed at gmail.com
Fri Dec 6 05:21:40 PST 2013



================
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());
----------------
Michele Scandale wrote:
> 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.
That makes sense (and I see you actually said that in the review upload and tests here that I didn't register; sorry 'bout that.)


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



More information about the cfe-commits mailing list