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