[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-02-16 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia closed this revision. Anastasia added a comment. Committed in 295311 https://reviews.llvm.org/D28058 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-02-15 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl accepted this revision. yaxunl added a comment. This revision is now accepted and ready to land. LGTM. Thanks! https://reviews.llvm.org/D28058 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-02-15 Thread Dmitry Borisenkov via Phabricator via cfe-commits
dmitry updated this revision to Diff 88529. dmitry added a comment. Byval attribute was added for ndrange in enqueue kernel call. https://reviews.llvm.org/D28058 Files: include/clang/AST/ASTContext.h include/clang/AST/BuiltinTypes.def include/clang/AST/Type.h

[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-01-13 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment. In https://reviews.llvm.org/D28058#645399, @dmitry wrote: > @yaxunl, we already have the similar issue for atomics. Probably we can > extend typedef semantic checks but I don't think it's a good idea since C and > C++ have the similar problem but they don't provide

[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-01-13 Thread Dmitry Borisenkov via Phabricator via cfe-commits
dmitry added a comment. @yaxunl, we already have the similar issue for atomics. Probably we can extend typedef semantic checks but I don't think it's a good idea since C and C++ have the similar problem but they don't provide special treatment for types from their standard libraries. I think

[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-01-11 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment. I am thinking whether we should restrict ndrange_t to be struct type only, otherwise a user could typedef anything as ndrange_t and we may lose the ndrange_t type in the IR, which will cause issue if we want to translate the IR to SPIRV.

[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-01-11 Thread Dmitry Borisenkov via Phabricator via cfe-commits
dmitry added a comment. Ping! https://reviews.llvm.org/D28058 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2016-12-23 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:2491 +llvm::Value *Range = NDRangeL.getAddress().getPointer(); +llvm::Type *RangeTy = NDRangeL.getAddress().getType(); I think following standard Clang CodeGen convention we should

[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2016-12-22 Thread Dmitry Borisenkov via Phabricator via cfe-commits
dmitry created this revision. dmitry added a reviewer: yaxunl. dmitry added subscribers: Anastasia, cfe-commits. Since we don't have an ideal option for ndrange_t implementation (which was discussed there: https://reviews.llvm.org/D23086), I propose to stick with identification by name approach