Page MenuHomePhabricator

azabaznov (Anton Zabaznov)
Compiler Engineer at Intel

Projects

User does not belong to any projects.

User Details

User Since
Sep 23 2020, 3:53 AM (37 w, 3 d)

Recent Activity

Wed, Jun 9

azabaznov added inline comments to D103911: [OpenCL] Add support of __opencl_c_images feature macro.
Wed, Jun 9, 5:12 AM · Restricted Project
azabaznov added a comment to D97869: [OpenCL] Add OpenCL builtin test generator.

@svenvh, are you going to add header-like output emitting?

Yes, I can add that if there is interest. I already have it on a local branch, so if there is interest (and it seems there is? :-)), then I will rebase that, tidy it up, and create a separate review.

Wed, Jun 9, 4:31 AM · Restricted Project
azabaznov added a comment to D97869: [OpenCL] Add OpenCL builtin test generator.

@svenvh, are you going to add header-like output emitting?

Wed, Jun 9, 4:12 AM · Restricted Project

Tue, Jun 8

azabaznov requested review of D103911: [OpenCL] Add support of __opencl_c_images feature macro.
Tue, Jun 8, 9:45 AM · Restricted Project
azabaznov added inline comments to D103241: [OpenCL] Add memory_scope_all_devices.
Tue, Jun 8, 3:48 AM · Restricted Project

Fri, Jun 4

azabaznov added a comment to D102853: [OpenCL] Align definition of __IMAGE_SUPPORT__ feature macro with OpenCL version and __opencl_c_images feature macro definition.

LGTM! Although I think it would be better if we set __IMAGE_SUPPORT__ conditionally also for earlier OpenCL versions.

Fri, Jun 4, 2:22 AM · Restricted Project

Tue, Jun 1

azabaznov added inline comments to D103401: [OpenCL] Add support of __opencl_c_generic_address_space feature macro.
Tue, Jun 1, 11:10 AM · Restricted Project
azabaznov added inline comments to D103401: [OpenCL] Add support of __opencl_c_generic_address_space feature macro.
Tue, Jun 1, 5:16 AM · Restricted Project
azabaznov added inline comments to D103191: [OpenCL] Add support of __opencl_c_program_scope_global_variables feature macro.
Tue, Jun 1, 5:04 AM · Restricted Project

Mon, May 31

azabaznov requested review of D103401: [OpenCL] Add support of __opencl_c_generic_address_space feature macro.
Mon, May 31, 4:31 AM · Restricted Project

Thu, May 27

azabaznov added inline comments to D103241: [OpenCL] Add memory_scope_all_devices.
Thu, May 27, 7:22 AM · Restricted Project
azabaznov added inline comments to D103241: [OpenCL] Add memory_scope_all_devices.
Thu, May 27, 4:41 AM · Restricted Project

Wed, May 26

azabaznov requested review of D103191: [OpenCL] Add support of __opencl_c_program_scope_global_variables feature macro.
Wed, May 26, 11:20 AM · Restricted Project

Fri, May 21

azabaznov committed rG826905787ae4: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64 (authored by azabaznov).
[OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64
Fri, May 21, 5:01 AM
azabaznov closed D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
Fri, May 21, 5:01 AM · Restricted Project

Thu, May 20

azabaznov requested review of D102853: [OpenCL] Align definition of __IMAGE_SUPPORT__ feature macro with OpenCL version and __opencl_c_images feature macro definition.
Thu, May 20, 10:05 AM · Restricted Project

Wed, May 19

azabaznov added inline comments to D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
Wed, May 19, 3:18 AM · Restricted Project
azabaznov updated the diff for D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

Drop one more formatting change from Sema.cpp

Wed, May 19, 3:11 AM · Restricted Project
azabaznov updated the diff for D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

Drop formatting changes from Sema.cpp

Wed, May 19, 3:08 AM · Restricted Project

Mon, May 17

azabaznov updated the diff for D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

Rebase after https://reviews.llvm.org/D100976; addressed review comments and updated docs.

Mon, May 17, 5:42 AM · Restricted Project

Fri, May 14

azabaznov added inline comments to D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
Fri, May 14, 7:43 AM · Restricted Project

May 7 2021

azabaznov added inline comments to D100980: [OpenCL] Allow use of double type without extension pragma.
May 7 2021, 11:32 AM · Restricted Project

May 6 2021

azabaznov updated the summary of D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
May 6 2021, 8:28 AM · Restricted Project
azabaznov updated the summary of D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
May 6 2021, 8:25 AM · Restricted Project
azabaznov updated the diff for D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

Rebased to use ::validateOpenCLTarget. Decided to use explicit simulatneous extensions/feature disabling in command line due to API spec limitations:

May 6 2021, 8:23 AM · Restricted Project

May 4 2021

azabaznov accepted D100980: [OpenCL] Allow use of double type without extension pragma.

Thanks! Looks good to me in general. See a comment.

May 4 2021, 10:00 AM · Restricted Project
azabaznov accepted D100983: [OpenCL] Fix optional image types.

LGTM. Thanks!

May 4 2021, 9:57 AM · Restricted Project

Apr 28 2021

azabaznov committed rGf0efc0075131: [OpenCL] Introduce new method for validating OpenCL target (authored by azabaznov).
[OpenCL] Introduce new method for validating OpenCL target
Apr 28 2021, 6:00 AM
azabaznov closed D101087: [OpenCL] Introduce new method for validating OpenCL target.
Apr 28 2021, 6:00 AM · Restricted Project
azabaznov added a comment to D100980: [OpenCL] Allow use of double type without extension pragma.

Not sure what do we want to achieve with this? Do you want to point out that the code might be somehow less portable let's say between clang revisions, etc?

Apr 28 2021, 3:43 AM · Restricted Project
azabaznov updated the diff for D101087: [OpenCL] Introduce new method for validating OpenCL target.

Add test for C++ for OpenCL diagnostics

Apr 28 2021, 3:08 AM · Restricted Project
azabaznov added inline comments to D100983: [OpenCL] Fix optional image types.
Apr 28 2021, 3:05 AM · Restricted Project
azabaznov added a comment to D100980: [OpenCL] Allow use of double type without extension pragma.

When the pragma is parsed we can't know why it is in the code to be able to issue any warning.

I mean diagnose once when, for example in your particular case, double type is parsed. Does it require much effort? I think this warning might be useful for developers who already rely on pragma usage in their kernels.

I am not sure I understand your suggestion. Could you show an example perhaps?

Apr 28 2021, 2:58 AM · Restricted Project

Apr 27 2021

azabaznov accepted D100983: [OpenCL] Fix optional image types.

Generally looks good to me, but maybe a test needed, see a comment. Thanks! But I'm still not sure about completely removing pragmas for type declarations (see https://reviews.llvm.org/D100980#2719196).

Apr 27 2021, 4:34 AM · Restricted Project
azabaznov added a comment to D100980: [OpenCL] Allow use of double type without extension pragma.

When the pragma is parsed we can't know why it is in the code to be able to issue any warning.

Apr 27 2021, 3:53 AM · Restricted Project
azabaznov added a comment to D100980: [OpenCL] Allow use of double type without extension pragma.

I am not sure, to be honest I personally think the extension pragma is a spec failure as it is not specified properly or to allow reasonable implementation

Apr 27 2021, 2:40 AM · Restricted Project

Apr 23 2021

azabaznov added a comment to D100980: [OpenCL] Allow use of double type without extension pragma.

We could of course keep it just for this particular case of doubles, but even half is allowed in certain circumstances without the pragma and it is still an extension. https://godbolt.org/z/K34sP81nx

Apr 23 2021, 9:00 AM · Restricted Project
azabaznov added inline comments to D101087: [OpenCL] Introduce new method for validating OpenCL target.
Apr 23 2021, 8:47 AM · Restricted Project
azabaznov updated the diff for D101087: [OpenCL] Introduce new method for validating OpenCL target.

Use LangOptions::getOpenCLVersionTuple() to provide diagnostics of OpenCL version

Apr 23 2021, 8:37 AM · Restricted Project
azabaznov added a comment to D100980: [OpenCL] Allow use of double type without extension pragma.

For cl_khr_fp64 I still want to keep the pragma for the other use case - to convert double literal into single-precision (https://github.com/KhronosGroup/OpenCL-Docs/issues/578). The reason why I think it could be useful is that the precision change might lead to a different result depending on the precision of the calculation. So I think pragmas could be useful to control whether double literal is single-precision or not to avoid this problem occur when code is compiled for different targets?

Apr 23 2021, 5:54 AM · Restricted Project
azabaznov updated the diff for D101087: [OpenCL] Introduce new method for validating OpenCL target.

Addressed comments, did some more refactoring. Is it OK to have "2.0" diagnostics for C++ for OpenCL?

Apr 23 2021, 4:43 AM · Restricted Project
azabaznov added a comment to D100980: [OpenCL] Allow use of double type without extension pragma.

do you think it is valuable to keep this behavior at all?

Apr 23 2021, 2:23 AM · Restricted Project
azabaznov accepted D100984: [OpenCL] Remove the need for subgroups extension pragma in enqueue kernel and pipe builtins.

LGTM!

Apr 23 2021, 2:05 AM · Restricted Project

Apr 22 2021

azabaznov added a comment to D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

Please see https://reviews.llvm.org/D101087.

Apr 22 2021, 10:31 AM · Restricted Project
azabaznov requested review of D101087: [OpenCL] Introduce new method for validating OpenCL target.
Apr 22 2021, 10:24 AM · Restricted Project
azabaznov added a comment to D100984: [OpenCL] Remove the need for subgroups extension pragma in enqueue kernel and pipe builtins.

Btw I am not suggesting removing the pragma. We will still have to parse it for backward compatibility. I am only dropping the requirement of using it in order to call get_kernel_max_sub_group_size_for_ndrange or get_kernel_sub_group_count_for_ndrange when the extension is supported. Because I don't see why this would be needed especially that all other functions from subgroups can be called without the pragma https://godbolt.org/z/MYavchPT3.

Apr 22 2021, 5:01 AM · Restricted Project
azabaznov added a comment to D100980: [OpenCL] Allow use of double type without extension pragma.

Same as for https://reviews.llvm.org/D100984, cl_khr_fp64 wasn't always core and thus it requires pragma for OpenCL C < 1.2 versions.

Apr 22 2021, 4:02 AM · Restricted Project
azabaznov added inline comments to D100976: [OpenCL] Simplify use of C11 atomic types.
Apr 22 2021, 3:51 AM · Restricted Project
azabaznov added a comment to D100984: [OpenCL] Remove the need for subgroups extension pragma in enqueue kernel and pipe builtins.

I wish it could be true... But cl_khr_subgroups still requires pragma in some versions as it wasn't a core feature earlier (https://www.khronos.org/registry/OpenCL/sdk/2.2/docs/man/html/cl_khr_subgroups.html).

Apr 22 2021, 3:40 AM · Restricted Project

Apr 21 2021

azabaznov added a comment to D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

My main idea was to provide an interface which will not make users to specify -cl-ext=+__opencl_c_fp64,+cl_khr_fp64/ -cl-ext=-__opencl_c_fp64,-cl_khr_fp64 if they need to enable/disable functionality in OpenCL C 3.0 because I believe that is not a right thing to do: why anyone should care about those extensions if there are features already? Also, this may lead to confusions since, for example, __opencl_c_subgroups and cl_khr_subgroups are not the same (subgroup independent forward progress is required in extension while it is optional in OpenCL C 3.0, thus implementation may support the extension but not the feature).

To be clear: I'm OK with providing a validation of correct option settings (__opencl_c_fp64/cl_khr_fp64 and __opencl_c_3d_image_writes/cl_khr_3d_image_writes should both be set to the same value). Also, it makes sense to unify a check within header and clang to the only macro, I'm OK with that too. But I would prefer to keep the option interface without redundant mentioning of extension.

Ok, let's implement both - we can add an early check of consistency of options and therefore will only need to use one for checking during the parsing and let's simplify the interface of -cl-ext. Since it is a frontend option and new functionality doesn't cause backward compatibility issues i.e. only affects OpenCL 3.0 onwards, so I see no risk. Could you please update the help documentation of the option explaining the new behavior? Then let's concentrate the whole logic for setting the options and keeping the consistency between the equivalent ones in TargetInfo::setCommandLineOpenCLOpts directly? This will provide cleaner flow due to encapsulation and will make it clear where the use case comes from. Does it make sense?

Apr 21 2021, 7:42 AM · Restricted Project

Apr 15 2021

azabaznov added inline comments to D100492: [OpenCL] Change OpenCL builtin version encoding.
Apr 15 2021, 11:13 AM · Restricted Project
azabaznov accepted D100492: [OpenCL] Change OpenCL builtin version encoding.

Great! And thanks for fixing misprint :)

Apr 15 2021, 6:47 AM · Restricted Project
azabaznov added a comment to D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

My main idea was to provide an interface which will not make users to specify -cl-ext=+__opencl_c_fp64,+cl_khr_fp64/ -cl-ext=-__opencl_c_fp64,-cl_khr_fp64 if they need to enable/disable functionality in OpenCL C 3.0 because I believe that is not a right thing to do: why anyone should care about those extensions if there are features already? Also, this may lead to confusions since, for example, __opencl_c_subgroups and cl_khr_subgroups are not the same (subgroup independent forward progress is required in extension while it is optional in OpenCL C 3.0, thus implementation may support the extension but not the feature).

Apr 15 2021, 6:39 AM · Restricted Project

Apr 9 2021

azabaznov updated the diff for D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

Remove unrelated change, fixed error in test to check only cl_khr_fp64 for OpenCL C < 1.2

Apr 9 2021, 6:28 AM · Restricted Project
azabaznov added inline comments to D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
Apr 9 2021, 6:19 AM · Restricted Project
azabaznov updated the diff for D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.

Addressed comments, rebased after refactoring: https://reviews.llvm.org/D97058

Apr 9 2021, 6:16 AM · Restricted Project

Apr 7 2021

azabaznov added a comment to D99969: [OpenCL] Accept .rgba in OpenCL 3.0.

Thanks for working on this! Looks good to me in general. I have a small comment.

Apr 7 2021, 1:17 AM · Restricted Project

Apr 1 2021

azabaznov added a comment to D99577: [RFC][OpenCL][PoC] Testing TableGen with diffing.

Thanks for feedback!

Apr 1 2021, 1:24 AM · Restricted Project

Mar 30 2021

azabaznov accepted D99425: [OpenCL] Fix parsing of opencl-c.h in CL 3.0.

Looks good to me. Thanks!

Mar 30 2021, 7:40 AM · Restricted Project
azabaznov updated the summary of D99577: [RFC][OpenCL][PoC] Testing TableGen with diffing.
Mar 30 2021, 5:14 AM · Restricted Project
azabaznov added a comment to D99425: [OpenCL] Fix parsing of opencl-c.h in CL 3.0.

Thanks for  the patch! Sorry for the delay

Mar 30 2021, 4:29 AM · Restricted Project
azabaznov requested review of D99577: [RFC][OpenCL][PoC] Testing TableGen with diffing.
Mar 30 2021, 3:59 AM · Restricted Project

Mar 16 2021

azabaznov added a comment to D97869: [OpenCL] Add OpenCL builtin test generator.

I have one more though.

Mar 16 2021, 5:10 AM · Restricted Project

Mar 15 2021

azabaznov added a comment to D98539: [OpenCL] Set target as spir for c-index-test for OpenCL.

@Anastasia, thanks for landing this! Sorry for delay, I though that this can wait until Monday

Mar 15 2021, 1:48 AM · Restricted Project
azabaznov added a comment to D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

Do you also get fatal error: 'opencl-c-base.h' file not found? If so, we might need at least to file a clang bug that we should look at before the next release.

Mar 15 2021, 1:47 AM · Restricted Project

Mar 12 2021

azabaznov added a comment to D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

Yes, I was able to reproduce the failure with -target arm64-apple-macosx flag, I provided the fix to set explicit target: https://reviews.llvm.org/D98539.

Mar 12 2021, 11:02 AM · Restricted Project
azabaznov requested review of D98539: [OpenCL] Set target as spir for c-index-test for OpenCL.
Mar 12 2021, 10:57 AM · Restricted Project
azabaznov added a comment to D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

Thanks guys,

Mar 12 2021, 10:21 AM · Restricted Project
azabaznov added a comment to D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

Yeah,  I'm looking into it, but I can't reproduce it locally: the test passes at x86_64 linux system. I'll revert the change if it takes too much time to investigate what's going on. Thanks.

Mar 12 2021, 9:55 AM · Restricted Project
azabaznov committed rG840643bbe1d2: [OpenCL] Refactor diagnostic for OpenCL extension/feature (authored by azabaznov).
[OpenCL] Refactor diagnostic for OpenCL extension/feature
Mar 12 2021, 12:44 AM
azabaznov closed D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.
Mar 12 2021, 12:44 AM · Restricted Project

Mar 10 2021

azabaznov added a comment to D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

Ok, addressing in a separate patch is reasonable, but why do you think that we will break backward compatibility? My current worry is that the implementation is so messy and inconsistent that it will take us longer time if we do the incremental steps. Also, we risk introducing the regressions since it is so hard to make sense out of it.

Mar 10 2021, 5:50 AM · Restricted Project
azabaznov updated the diff for D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

Replaced atomic_double implicit definition

Mar 10 2021, 12:32 AM · Restricted Project
azabaznov updated the diff for D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

Corrected some mistakes, added a test for diagnosing undeclared identifiers when a extension is unsupported. Generally leaving the change as it is as completely removing pragma may break backward compatibility now: let's do it in a separate patch and notify everyone before doing that. Also, we should wait before spec will be finalized.

Mar 10 2021, 12:11 AM · Restricted Project

Mar 4 2021

azabaznov added a comment to D97869: [OpenCL] Add OpenCL builtin test generator.

That's awesome!

Mar 4 2021, 5:29 AM · Restricted Project
azabaznov added inline comments to D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.
Mar 4 2021, 1:03 AM · Restricted Project

Mar 3 2021

azabaznov added inline comments to D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.
Mar 3 2021, 6:38 AM · Restricted Project
azabaznov updated the diff for D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

Check 'isEnabled' is now private: it is used only for non-core or non-optional core features;
creation of implicit type definitions is guarder with extension support check; minor refactoring

Mar 3 2021, 6:27 AM · Restricted Project

Mar 2 2021

azabaznov added a comment to D97052: [OpenCL] Prevent adding extension pragma by default.

Thanks for working on this. LGTM in general. I'll let Marco comment on the latest changes.

Mar 2 2021, 12:53 AM · Restricted Project

Feb 25 2021

azabaznov added a comment to D97052: [OpenCL] Prevent adding extension pragma by default.

I see the update regaring this functionality on github issue: https://github.com/KhronosGroup/OpenCL-Docs/issues/82#issuecomment-785496025. Is it a right way to reflect this information in`OpenCLExtensions.def`?

Feb 25 2021, 1:18 AM · Restricted Project
azabaznov added a comment to D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.

FYI, I would even be ok if we remove the need for enabling non-core

Feb 25 2021, 1:15 AM · Restricted Project
azabaznov added inline comments to D97052: [OpenCL] Prevent adding extension pragma by default.
Feb 25 2021, 12:59 AM · Restricted Project

Feb 20 2021

azabaznov added inline comments to D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
Feb 20 2021, 12:15 AM · Restricted Project
azabaznov added inline comments to D97052: [OpenCL] Prevent adding extension pragma by default.
Feb 20 2021, 12:12 AM · Restricted Project

Feb 19 2021

azabaznov added inline comments to D97052: [OpenCL] Prevent adding extension pragma by default.
Feb 19 2021, 10:31 AM · Restricted Project
azabaznov added a comment to D97052: [OpenCL] Prevent adding extension pragma by default.

Thanks! I review is shortly. As for now, I also was doing some refactoring: https://reviews.llvm.org/D97058. Check-clang passes, as I see there are no conflicts for now.

Feb 19 2021, 8:54 AM · Restricted Project
azabaznov requested review of D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature.
Feb 19 2021, 8:51 AM · Restricted Project

Feb 17 2021

azabaznov committed rGe1a64aa66c33: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode (authored by azabaznov).
[OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode
Feb 17 2021, 1:19 AM
azabaznov closed D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode.
Feb 17 2021, 1:19 AM · Restricted Project

Feb 16 2021

azabaznov added a comment to D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode.

Thanks for review. Last change is a small fix for if clang-tidy warnings

Feb 16 2021, 7:06 AM · Restricted Project
azabaznov updated the diff for D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode.

Fix clang-tidy warnings

Feb 16 2021, 7:05 AM · Restricted Project

Feb 15 2021

azabaznov added inline comments to D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
Feb 15 2021, 1:18 AM · Restricted Project

Feb 12 2021

azabaznov added inline comments to D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode.
Feb 12 2021, 11:50 AM · Restricted Project
azabaznov updated the diff for D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode.

Rewrote 'RemoveAddressSpaceFromPtr' to return canonical type

Feb 12 2021, 11:41 AM · Restricted Project

Feb 11 2021

azabaznov requested review of D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64.
Feb 11 2021, 9:57 AM · Restricted Project

Feb 10 2021

azabaznov added a comment to D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode.

Thanks for review. Just to be clear: can I proceed with this? Or we should discuss it first? As I see possible this change can be abandoned after discussion.

Feb 10 2021, 8:29 AM · Restricted Project

Feb 5 2021

azabaznov requested review of D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode.
Feb 5 2021, 2:00 PM · Restricted Project
azabaznov committed rGd88c55ab95c9: [OpenCL] Add macro definitions of OpenCL C 3.0 features (authored by azabaznov).
[OpenCL] Add macro definitions of OpenCL C 3.0 features
Feb 5 2021, 7:43 AM
azabaznov closed D95776: [OpenCL] Add macro definitions of OpenCL C 3.0 features.
Feb 5 2021, 7:42 AM · Restricted Project
azabaznov committed rGa5b627aa4fe7: [OpenCL] Introduce new language options for OpenCL keywords. (authored by azabaznov).
[OpenCL] Introduce new language options for OpenCL keywords.
Feb 5 2021, 12:19 AM