[cfe-dev] [RFC] Add SYCL programming model support.
Anastasia Stulova via cfe-dev
cfe-dev at lists.llvm.org
Wed Feb 6 03:49:16 PST 2019
Hi Alexey,
Sorry for the delay. It took me sometime to look at your prototype in github. It seems quite a substantial amount of work!
I have provided my feedback on your review already https://reviews.llvm.org/D57768 but I think the topics mainly belong here.
There are a number of big architectural aspects of Clang that this work affects. My personal feeling is that some more senior developers in Clang architecture should provide feedback.
Particularly, the following aspects require more attention:
* SYCL seems to require adding tight dependencies from the standard libraries into the compiler because many language features are hidden behind library classes. This is not common for Clang. We had a discussion about this issue during the implementation of OpenCL C++ and it was decided not to go this route for upstream Clang. Can you explain your current approach to implement this?
* I am not sure how the change of direction for OpenCL C++ to just enabling C++ in OpenCL would affect your work now? Particularly we are establishing a lot of rules in the areas of interplay between OpenCL features and C++. Address space handling is one example here. As far as I am aware SYCL doesn't detail many of these rules either. So I am wondering how it would work... would you just inherit the same rules? Also keep in mind they are not documented anywhere yet other than the source code. Additionally for the address spaces we are trying to generalize the rules as much as possible rather than just adding separate language checks all over. It would be nice if you adhere to this approach too!
* What is your solution for integration with SPIR-V and how does it relate to our previous discussions in October: http://lists.llvm.org/pipermail/cfe-dev/2018-October/059974.html
* Can you explain the purpose of https://github.com/intel/llvm/tree/sycl/clang/lib/CodeGen/OclCxxRewrite that you are adding to Clang?
Cheers,
Anastasia
________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Bader, Alexey via cfe-dev <cfe-dev at lists.llvm.org>
Sent: 30 January 2019 22:06
To: David Airlie
Cc: cfe-dev (cfe-dev at lists.llvm.org)
Subject: Re: [cfe-dev] [RFC] Add SYCL programming model support.
Hi Dave,
Thanks for your comments.
We definitely will integrate address spaces support required for SYCL into ToT. The code currently uploaded to the GitHub is our first approach to implement SYCL address spaces inference rules, but we found that it is not robust and difficult to maintain. We are working on alternative implementation emitting "raw" pointers (i.e. w/o specified address space) in "generic" address space and later re-using existing LLVM pass to inference address space.
This approach should be aligned with existing implementation of address spaces for OpenCL C++.
Thanks,
Alexey
-----Original Message-----
From: David Airlie [mailto:airlied at redhat.com]
Sent: Monday, January 28, 2019 9:45 PM
To: Bader, Alexey <alexey.bader at intel.com>
Cc: cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [RFC] Add SYCL programming model support.
On Sat, Jan 26, 2019 at 6:11 AM Bader, Alexey via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>
> Hi,
>
>
>
> A short update: we uploaded SYCL compiler and runtime sources to the GitHub https://github.com/intel/llvm/tree/sycl.
>
>
>
> Thanks to all who provided feedback and expressed interest in this project (mostly off the clang mailing list).
>
> If there are no objections, we are going to start sending patches for review in a week or two.
Hi Alexey,
I've just started looking over this, and first of all great work! I'm not directly the best person yet to review all of this, but I'm starting to look over it and one thing stood out:
There seems to be some interaction or reliance on old address space behaviour,
I don't think (maybe I'm wrong) that upstream will want to accept:
[SYCL] Revert "[OpenCL] Enable address spaces for references in C++"
or at least the OpenCL C++ people need to be talked to.
Is there some more work that could be done in these to avoid the revert?
[SYCL] Implement SYCL address-space rules.
- do we have to use separate sycl address spaces as at all here btw?
or are the opencl ones defined already not sufficient?
[SYCL] Add SYCL-specific address spaces fixer pass.
Dave.
--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190206/17af8222/attachment.html>
More information about the cfe-dev
mailing list