Anastasia added inline comments.

================
Comment at: lib/CodeGen/CGOpenCLRuntime.cpp:43
@@ +42,3 @@
+
+  return llvm::StructType::create(EleTypes, "ndrange_t");
+}
----------------
yaxunl wrote:
> Anastasia wrote:
> > yaxunl wrote:
> > > yaxunl wrote:
> > > > struct name should be "struct.ndrange_t" to allow library code to 
> > > > access it.
> > > Sorry, should be "struct.__ndrange_t" to avoid conflict with builtin type 
> > > ndrange_t.
> > Is there any conflict really? I think it should be Ok to keep 
> > "struct.ndrange_t", since we transform it to a struct and don't declare as 
> > struct.
> ndrange_t is defined as a builtin type in Clang, so library developer cannot 
> implement it as a concrete type, but they can implement `__ndrange_t`. This 
> is similar to the case of `as_type`.
I am not sure I am following you, but I think this is different now from other 
OpenCL types because it's not an opaque type and this change gives it a 
concrete structure.

Technically we can give it any name really struct.ndrange_t or 
`struct.__ndrange_t` would do because declaring a new type with ndrange_t 
identifier would be disallowed in OpenCL code and all `__` prefixed identifiers 
are reserved for internal toolchain use.

But not sure why we would go for `struct.__ndrange_t`. We can leave this 
identifier to be still available for toolchain if needed.


Repository:
  rL LLVM

https://reviews.llvm.org/D23086



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to