- User Since
- Dec 18 2017, 12:01 AM (120 w, 3 d)
Tue, Apr 7
Mon, Apr 6
Tue, Mar 31
Apply comments, rebase.
Mon, Mar 30
Rebased to fresh version. Applied fixes after https://reviews.llvm.org/D70172
Fri, Mar 27
Mon, Mar 23
Fix the test by adding the target with __float128 support and make sure that
no diagnostic are emitted.
Fri, Mar 20
Added diagnosing of __float128 type usage.
See the summary of revision for details.
Feb 27 2020
@rjmccall, Thank you very much for so detailed response, It really helps. I started working on implementation and I have a couple of questions/problems with this particular appoach.
Feb 17 2020
Feb 13 2020
I haven't considered something like this, because I'm not familiar with ObjC at all... I will give it a try, thanks.
Feb 11 2020
Jan 21 2020
Thank you for this!
Dec 13 2019
Dec 10 2019
Updated tests using address space attributes added by D71005
Dec 4 2019
Dec 2 2019
LGTM with a couple of minor comments.
Nov 30 2019
A couple of minor comments.
Jun 27 2019
Added warning diagnostic for sycl_kernel attribute.
Jun 24 2019
Jun 20 2019
Fixed a couple coding style issues, renamed markDevice function with markSYCLDevice.
Updated sycl_kernel attribute documentation.
Jun 19 2019
Appled part of comments from @aaron.ballman:
- Fixed grammar and code style in all places except sycl_kernel docs
- Added a lit test which checks that sycl_device attribute implicitly added to proper declarations
Jun 18 2019
Jun 11 2019
@aaron.ballman , please let me know if you have additional comments/suggestions. If not, could you please accept this revision?
Jun 10 2019
Applied comments from @Anastasia
Jun 3 2019
May 31 2019
May 30 2019
May 28 2019
Applied comments from @Anastasia
- Added documentation for sycl_kernel function
- Added comments to Sema.h
- Added -std=c++11 to test run lines
May 23 2019
May 22 2019
May 21 2019
Added semantics for new attributes
Apr 19 2019
I tried to reuse OpenCL kernel attribute with "__kernel" keyword in our current SYCL implementation. PR with this try is here - https://github.com/intel/llvm/pull/97
Now It looks feasible but with a couple notes:
From SYCL specification "SYCL is designed to be as close to standard C++ as possible. Standard C++ compiler can compile the SYCL programs and they will run correctly on host CPU." So SYCL doesn't provide non-standard kernel keyword which is provided by OpenCL. Due this fact it's not possible to add kernel keyword as in OpenCL, it will prevent compilation of following valid SYCL code:
Apr 17 2019
Apr 16 2019
I'm not an expert in clang terminology but I will try briefly explain our current implementation approach.
In SYCL all kernel functions should be template functions so these functions have a deferred instantiation. If we found that we instantiated a sycl kernel function - we add it to a special array with sycl device functions (you can see the corresponding code here and here, actually AddSyclKernel adds declaration to the special array inside the Sema). After performing
pending instantiations we run a recursive AST visitor for each SYCL kernel to mark all device functions and add them to a special array with SYCL device functions (here we start traverse AST from MarkDevice function, code of MarkDevice is here).
To get a correct set of SYCL device functions in produced module we added a check for all declarations inside the CodeGen on sycl_device attribute existence - so it will ignore declarations without sycl_device attribute if we are compiling for SYCL device (code is here). But with this check it's possible situation when function was parsed and ignored by the CodeGen before we added `sycl_device' attribute to it so we added yet another parsing action inside the clang::ParseAST to generate code for all SYCL device functions from the special array (code is here).
Apr 15 2019
Applied comment from @bader.
Applied comments from @bader
Apr 12 2019
Apr 9 2019
Feb 22 2018
Overhead not reproduced on latest version of LLVM.
Feb 11 2018
Yes, we don't have anything OpenCL specific for atomic pointers.
But we have OpenCL specific in pointers and atomics separately and we have address spaces.
Why not to test all at once?