yaxunl added a comment. In https://reviews.llvm.org/D23086#515443, @Anastasia wrote:
> In https://reviews.llvm.org/D23086#514279, @yaxunl wrote: > > > How about we decide if a type is ndrange_t type based on their canonical > > types. If the canonical type of type X is the same as the canonical type of > > ndrange_t type, then type X is treated as ndrange_t type. Is this > > reasonable? > > > I am not sure I understand entirely what you mean? > > Following the earlier suggestion from David, I think we can just create a > struct type internally and then typedef it to ndrange_t, we can use > buildImplicitRecord and addImplicitTypedef methods I believe. The latter one > has already been used for other OpenCL types. > > We will have to switch to string comparisons to identify this type in > SemaChecking.cpp and CGBuiltins.cpp for handling the enqueue_kernel call. This was not the approach we agreed upon. The approach we agreed upon was In https://reviews.llvm.org/D23086#507215, @majnemer wrote: > In https://reviews.llvm.org/D23086#507203, @yaxunl wrote: > > > How about assuming ndrange_t is a struct type defined by user and identify > > it by struct type name in Clang? This gives user freedom of implementing it > > differently than SPIR. In opencl-c.h define it as a struct type as SPIR > > required. > > > That sounds fine to me. The issue of your approach is that vendors lose the freedom to define ndrange_t the way they like. 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
