[cfe-dev] [RFC] Add SYCL programming model support.

Wed Feb 6 07:13:52 PST 2019

Hi Alexey,

> Let me check that I understand this question correctly. Are you asking about implementation of pointer classes representing pointers to different address spaces?

As for address spaces I think you can shortcut by mapping to OpenCL address spaces indeed. Although I don't know why address space qualifiers wouldn't be used directly actually? At some point I would like to enable address spaces without "__" prefix btw to allow porting OpenCL C code to C++. Not sure if it can create issues for SYCL then. But it's worth making this clear now.

However, I think for SYCL address spaces is just one example of much broader picture? What about all other language features that are wrapped into the libraries? For example the code in SemaOverload.cpp of this commit illustrates that you need a tight coupling between compiler and library.
https://github.com/intel/llvm/commit/03354a29868b79a30e6fb2c8311bb409a8cc2346#diff-811283eaa55fa65f65713fdd7ecaf4aa

> I need better understand the “OpenCL C++ route” and how it’s aligned with SYCL design philosophy, which tries to enable programing of accelerators via “extension-free” standard C++.

As for OpenCL we are just enabling C++ functionality to work in OpenCL. That would mean all the library based language features from OpenCL C++ won't be implemented. Btw, I feel there is a little contradiction here because if you can just use “extension-free” standard C++ then you wouldn't need to modify Clang?

> Current implementation relies on existing “LLVM to SPIR-V” translator [1]. It’s integrated as an external tool into the toolchain for SYCL. We would like LLVM to have native support of SPIR-V format, so we rely on your work here.

Just to understand: do you plan to add a SPIR-V triple to Clang&LLVM and a special action into Clang that would invoke the translator after generation of IR? If yes I would quite like to see it done more generically in Clang and not just for SYCL. But I think there were some concerns from the other members of LLVM. I will let them comment if it's still the case.

> We re-used the OpenCL C++ compiler component here to emit LLVM IR for the “LLVM to SPIR-V” translator. For instance, this pass adjusts accelerator specific data types to the format recognized by the translator [2]. I’m open to the suggestions how to improve the format, so we don’t need “adjusting passes”.

Just to be more specific I guess you mean the OpenCL C++ prototype compiler here (which is quite different from the implementation in mainline Clang)? Can you explain what kind of adjustments you are trying to make and why the approach from OpenCL C wouldn't apply in your case?

> Anyway https://reviews.llvm.org/D57768 is not related to these topics and it’s aligned with existing CUDA/OpenMP functionality.

As I wrote, these comments are not to the review but they are conceptually important aspects that the community should align on. It might be good to have a concrete plan before starting to work on something?

Cheers,
Anastasia

________________________________
From: Bader, Alexey <alexey.bader at intel.com>
Sent: 06 February 2019 13:18
To: Anastasia Stulova; David Airlie; clang-dev developer list
Cc: nd
Subject: RE: [cfe-dev] [RFC] Add SYCL programming model support.

Hi Anastasia,

Thanks for your feedback.

I agree that some SYCL features require in-depth review from compiler implementers and I mentioned some them in my original email.

  *   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?

Let me check that I understand this question correctly. Are you asking about implementation of pointer classes representing pointers to different address spaces?

I need better understand the “OpenCL C++ route” and how it’s aligned with SYCL design philosophy, which tries to enable programing of accelerators via “extension-free” standard C++. The implementation of SYCL pointers classes relies on the device compiler extension enabling new keywords like `__global`, `__local`, etc., but these are not exposed to the user.

The way we expose this functionality to the user is one aspect of this feature, another important part is integration with existing C++ code, which doesn’t use new extensions or pointer wrapper classes, but still want to execute on accelerator.

  *   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!

I think it’s common interest to share as much as possible and do not diverge implementations enabling similar functionality.

So I think it would be great if you can document the way you see address spaces integrated into C++.

  *   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

Current implementation relies on existing “LLVM to SPIR-V” translator [1]. It’s integrated as an external tool into the toolchain for SYCL. We would like LLVM to have native support of SPIR-V format, so we rely on your work here.

  *   Can you explain the purpose of https://github.com/intel/llvm/tree/sycl/clang/lib/CodeGen/OclCxxRewrite that you are adding to Clang?

We re-used the OpenCL C++ compiler component here to emit LLVM IR for the “LLVM to SPIR-V” translator. For instance, this pass adjusts accelerator specific data types to the format recognized by the translator [2]. I’m open to the suggestions how to improve the format, so we don’t need “adjusting passes”.

Anyway https://reviews.llvm.org/D57768 is not related to these topics and it’s aligned with existing CUDA/OpenMP functionality.

Thanks,

Alexey

[1] https://github.com/KhronosGroup/SPIRV-LLVM-Translator

[2] https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/master/docs/SPIRVRepresentationInLLVM.rst

From: Anastasia Stulova [mailto:Anastasia.Stulova at arm.com]
Sent: Wednesday, February 6, 2019 2:49 PM
To: David Airlie <airlied at redhat.com>; Bader, Alexey <alexey.bader at intel.com>; clang-dev developer list <cfe-dev at lists.llvm.org>
Cc: nd <nd at arm.com>
Subject: Re: [cfe-dev] [RFC] Add SYCL programming model support.

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<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Bader, Alexey via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: 30 January 2019 22:06
To: David Airlie
Cc: cfe-dev (cfe-dev at lists.llvm.org<mailto: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<mailto:alexey.bader at intel.com>>
Cc: cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>) <cfe-dev at lists.llvm.org<mailto: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<mailto: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<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

--------------------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190206/4c0e5089/attachment.html>