[PATCH] [NVPTX] kernel pointer arguments point to the global address space

[Jingyue Wu]

================
Comment at: lib/Target/NVPTX/NVPTXLowerKernelArgs.cpp:37
@@ +36,3 @@
+//      %input2 = bitcast float* %input to i8*
+//      %cvt = call i8 addrspace(1)* @llvm.nvvm.ptr.gen.to.global.p1i8.p0i8(i8* %input2)
+//      %input3 = bitcast i8 addrspace(1)* %cvt to float addrspace(1)*
----------------
jholewinski wrote:
> The address space conversion intrinsics are deprecated in favor of the new addrspacecast instruction (I need to document that in IntrinsicsNVVM.td).
Thank you for pointing this out. So, do you think we should emit addrspacecast here too instead of gen.to.global and gen.to.param? 

================
Comment at: lib/Target/NVPTX/NVPTXLowerKernelArgs.cpp:40
@@ +39,3 @@
+//      %input4 = addrspacecast float addrspace(1)* %input3 to float*
+//      %v = load float, float* %input4, align 4
+//      ...
----------------
jholewinski wrote:
> Isn't it possible that an optimization would remove all of these casts before NVVMFavorNonGenericAddrSpaces runs?  I know we control the pass pipeline in the backend, but I worry about these pass ordering constraints.
Not sure. Removing bitcast is fine for NVPTXFavorNonGenericAddrSpace. Why would any pass remove addrspacecast? addrspacecast has a richer semantics -- it changes the address space of a pointer and accessing pointers in different address spaces are not necessarily as fast. If any pass would want to remove an addrspacecast, it should reason about the performance effects of that too. 

================
Comment at: lib/Target/NVPTX/NVPTXLowerKernelArgs.cpp:189
@@ +188,3 @@
+      else
+        handlePointerParam(&Arg);
+    }
----------------
jholewinski wrote:
> Strictly speaking, this is only valid for CUDA (DrvInterface::CUDA).
ACK

http://reviews.llvm.org/D10154

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/