User Details
- User Since
- Sep 23 2020, 3:53 AM (22 w, 6 d)
Today
Thanks for working on this. LGTM in general. I'll let Marco comment on the latest changes.
Thu, Feb 25
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`?
FYI, I would even be ok if we remove the need for enabling non-core
Sat, Feb 20
Fri, Feb 19
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.
Wed, Feb 17
Tue, Feb 16
Thanks for review. Last change is a small fix for if clang-tidy warnings
Fix clang-tidy warnings
Mon, Feb 15
Fri, Feb 12
Rewrote 'RemoveAddressSpaceFromPtr' to return canonical type
Thu, Feb 11
Wed, Feb 10
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.
Fri, Feb 5
Thu, Feb 4
Adjusted test one more time: moved header functionality into separate test
Features remain defined in header for OpenCL C 2.0; adjusted the test
Renamed language options and adjusted comment.
Tue, Feb 2
Rebased one more time
Rebased
Rebased
Mon, Feb 1
I suggest that renaming 'extension' to 'option' (extensions + features) concept to be done in separate commit. There are a lot of places to change all over the place in clang.
Due to refactoring in https://reviews.llvm.org/D92277 this flow is no longer valid. New patch for this functionality is here: https://reviews.llvm.org/D95776.
Jan 25 2021
Jan 22 2021
Removed getCoreFeatures() as it's not used in this change.
Jan 21 2021
Thanks for feedback. I agree that providing diagnostics for unsupported core features is enough for now (I guess I'll try to come up with something for OpenCL C 3.0 features to set them unconditionally for 2.0, or at least these macros can be defined in header only). So I removed setting of core features (and also addressed all cosmetic concerns).
Jan 20 2021
Jan 18 2021
Jan 14 2021
Changes in the latest patch:
Dec 13 2020
Dec 9 2020
Changes in the latest patch:
Dec 1 2020
Thanks for working on this! It is a very good refactoring that brings OpenCL closer inline with convention design flow
Nov 29 2020
I didn't want to end up with a big refactoring from this patch but now I start to think that considering the situation it might be unavoidable. :(
@Anastasia, there is common functionality with your approach in https://reviews.llvm.org/D91531. I guess these two patches can be unified at some point once we discuss it.
Nov 24 2020
Addressed almost all technical and cosmetic concerns. Except putting reference of OpenCLOptions in Sema due to const of TargetInfo. I am going to think about that later. Also:
Hi! Great to see the interest in OpenCL C 3.0!
Nov 23 2020
So if I understand it well you are suggesting to perform a check for every parsed macro definition that would identify whether the macro has a name matching what is provided in -cl-ext=? Then if the name matches it would check whether the macro should be defined or not?
Perhaps if you give me an example it would help to understand
Nov 19 2020
Yes, in general this approach looks good to me conceptually. I have two suggestions:
Nov 18 2020
Nov 17 2020
Nov 11 2020
What did you think in mind regarding activation of features for SPIR?
Addressed all concerns except replacing __opencl_c_int64 definition into header. The reason for this as follows: this macro should be predefined regardless if clang includes default header or not.
Nov 6 2020
I guess targets like SPIR will be supporting all features by default?
Oct 21 2020
Oct 14 2020
Looks good to me, thanks for the note.
Oct 9 2020
Anastasia, Sven, thanks for the review! Anastasia, it seems that I don't have write access yet. Would you mind landing this change on behalf of me? Thanks!