- User Since
- Jun 22 2016, 9:03 AM (165 w, 3 d)
Jan 23 2018
Removed dereferenced_type specialization for non-dereferenceable type. Thus we could use detection idiom (e.g. std::experimental:: detected_or) with it in future.
Jan 22 2018
Jan 13 2018
@yaxunl there are two benefits of this change.
- As pointed by Anastasia. Currently, we have values of addressing mode flags so that they produce valid addressing mode if to combine some of them (see Anastasia's example). And the spec (https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/sampler_t.html) says addressing mode must be one of CLK_ADDRESS_REPEAT, CLK_ADDRESS_CLAMP_TO_EDGE, CLK_ADDRESS_CLAMP, CLK_ADDRESS_NONE. Though the spec doesn't require it, it's still better to diagnose if a developer specified multiple addressing modes.
- In current implementation filtering modes and normalized coordinates might be omitted when initializing samplers. The spec again says that these fields must be one of the predefined enums. Thus having defaults (i.e. constants of 0 values) allow a developer to omit some of the modes and write less portable code which is harder to debug.
Jan 3 2018
Nov 29 2017
@yaxunl, I moved IMAGE_SUPPORT macro definition so that now it's guarded by LangOpts.OpenCL
Could you kindly take a second look to the review. Thanks.
Nov 27 2017
Guarded #define IMAGE_SUPPORT 1 with OpenCL
Nov 24 2017
Ping. @yaxunl, could you kindly review the patch? It's just a few lines of code.
Nov 20 2017
Apr 26 2017
Apr 21 2017
@mcrosier, I can't. The main motivation is an out-of-tree target, but that it might be beneficial for other targets as well.
Apr 20 2017
Ping. Richard, do you think you'll be able to take a look at this small change?
Apr 6 2017
Apr 5 2017
@yaxunl, could you kindly review the patch? It's quite short this time.
Mar 29 2017
Feb 16 2017
Feb 15 2017
Byval attribute was added for ndrange in enqueue kernel call.
Jan 13 2017
@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 the proposed approach conforms to general practice and I also think that it's better than to check canonical type and therefore to restrict ndrange_t with a particular non-standard implementation or do you envision something different from the canonical type checking in mind?
Jan 11 2017