[PATCH] D18051: [CUDA] Provide CUDA's vector types implemented using clang's vector extension.

[Justin Lebar via cfe-commits]

jlebar added inline comments.

================
Comment at: lib/Headers/__clang_cuda_runtime_wrapper.h:72
@@ -71,1 +71,3 @@
 
+#if defined(CUDA_VECTOR_TYPES)
+// Prevent inclusion of CUDA's vector_types.h
----------------
The compiler driver is responsible for enabling/disabling language extensions, and for choosing exactly which dialect we accept.  It's also responsible for deciding which optimizations to use.  This fits in all of those ways.

Moreover, again, -Dfoo won't appear in --help, so, from a user's perspective, is undiscoverable.  In the event that they do discover it somehow, there's no documentation attached to the flag.

I am not aware of any switches built into clang that rely on -D.  If you really want to do it this way, can you point me to prior art?

================
Comment at: lib/Headers/__clang_cuda_vector_types.h:81
@@ +80,3 @@
+      : x(__x), y(__y), z(__z) {}
+  __attribute__((host, device)) explicit dim3(uint3 __a)
+      : x(__a.x), y(__a.y), z(__a.z) {}
----------------
Huh, apparently we do want to use the reserved namespace?

If so, this logic applies very strongly to a -D, which is going to be far more user-visible than the arg names here.

================
Comment at: lib/Headers/__clang_cuda_vector_types.h:83
@@ +82,3 @@
+      : x(__a.x), y(__a.y), z(__a.z) {}
+  __attribute__((host, device)) operator uint3(void) { return {x, y, z}; }
+};
----------------
If I'm understanding correctly, you're saying that if we have

  struct dim3 {
    dim3(unsigned, unsigned, unsigned);
    dim3(uint3);
  };

  void foo(dim3);

that the call

  uint3 x;
  foo(x);

is ambiguous, because it could call either dim3 constructor overload?

That is bizarre, but if so, do we need the dim3(uint3) constructor at all?


http://reviews.llvm.org/D18051