<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Hi Alexey,</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<div style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<div>> Let me check that I understand this question correctly. Are you asking about implementation of pointer classes representing pointers to different address spaces?<br>
<br>
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.<br>
</div>
<div><br>
</div>
<div>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. <br>
https://github.com/intel/llvm/commit/03354a29868b79a30e6fb2c8311bb409a8cc2346#diff-811283eaa55fa65f65713fdd7ecaf4aa<br>
</div>
<div><br>
> 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++.
<br>
<br>
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?<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
> 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”.<br>
<br>
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?<br>
<br>
> Anyway https://reviews.llvm.org/D57768 is not related to these topics and it’s aligned with existing CUDA/OpenMP functionality.<br>
<br>
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?</div>
<div><br>
</div>
</div>
<div style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
Cheers,</div>
<div style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
Anastasia<br>
</div>
<div style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Bader, Alexey <alexey.bader@intel.com><br>
<b>Sent:</b> 06 February 2019 13:18<br>
<b>To:</b> Anastasia Stulova; David Airlie; clang-dev developer list<br>
<b>Cc:</b> nd<br>
<b>Subject:</b> RE: [cfe-dev] [RFC] Add SYCL programming model support.</font>
<div> </div>
</div>
<div link="blue" vlink="purple" lang="EN-US">
<div class="x_WordSection1">
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Hi Anastasia,</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Thanks for your feedback.</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">I agree that some SYCL features require in-depth review from compiler implementers and I mentioned some them in my original email.</span></p>
<ul type="disc">
<li class="x_MsoNormal" style="color:black"><span style="font-family:"Calibri",sans-serif">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?</span></li></ul>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Let me check that I understand this question correctly. Are you asking about implementation of pointer classes representing pointers to different address
spaces? </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">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.
</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">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.
</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<ul type="disc">
<li class="x_MsoNormal" style="color:black"><span style="font-family:"Calibri",sans-serif">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!</span></li></ul>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">I think it’s common interest to share as much as possible and do not diverge implementations enabling similar functionality.</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">So I think it would be great if you can document the way you see address spaces integrated into C++.</span></p>
<ul type="disc">
<li class="x_MsoNormal" style="color:black"><span style="font-family:"Calibri",sans-serif">What is your solution for integration with SPIR-V and how does it relate to our previous discussions in October:
<a href="http://lists.llvm.org/pipermail/cfe-dev/2018-October/059974.html" target="_blank">
http://lists.llvm.org/pipermail/cfe-dev/2018-October/059974.html</a></span></li></ul>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">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.</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<ul type="disc">
<li class="x_MsoNormal" style="color:black"><span style="font-family:"Calibri",sans-serif">Can you explain the purpose of
<a href="https://github.com/intel/llvm/tree/sycl/clang/lib/CodeGen/OclCxxRewrite" target="_blank">
https://github.com/intel/llvm/tree/sycl/clang/lib/CodeGen/OclCxxRewrite</a> that you are adding to Clang?</span></li></ul>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">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”.</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Anyway https://reviews.llvm.org/D57768 is not related to these topics and it’s aligned with existing CUDA/OpenMP functionality.</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Thanks,</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Alexey</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">[1]
<a href="https://github.com/KhronosGroup/SPIRV-LLVM-Translator">https://github.com/KhronosGroup/SPIRV-LLVM-Translator</a></span><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black"></span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">[2]
<a href="https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/master/docs/SPIRVRepresentationInLLVM.rst">
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/master/docs/SPIRVRepresentationInLLVM.rst</a></span></p>
<p class="x_MsoNormal"><a name="x__MailEndCompose"> </a></p>
<div>
<div style="border:none; border-top:solid #E1E1E1 1.0pt; padding:3.0pt 0cm 0cm 0cm">
<p class="x_MsoNormal"><a name="x______replyseparator"></a><b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> Anastasia Stulova [mailto:Anastasia.Stulova@arm.com]
<br>
<b>Sent:</b> Wednesday, February 6, 2019 2:49 PM<br>
<b>To:</b> David Airlie <airlied@redhat.com>; Bader, Alexey <alexey.bader@intel.com>; clang-dev developer list <cfe-dev@lists.llvm.org><br>
<b>Cc:</b> nd <nd@arm.com><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Add SYCL programming model support.</span></p>
</div>
</div>
<p class="x_MsoNormal"> </p>
<div id="x_divtagdefaultwrapper">
<div id="x_divtagdefaultwrapper">
<p><span style="font-family:"Calibri",sans-serif; color:black">Hi Alexey,</span></p>
<p><span style="font-family:"Calibri",sans-serif; color:black"> </span></p>
<p><span style="font-family:"Calibri",sans-serif; color:black">Sorry for the delay. It took me sometime to look at your prototype in github. It seems quite a substantial amount of work!</span></p>
<p><span style="font-family:"Calibri",sans-serif; color:black"> </span></p>
<p><span style="font-family:"Calibri",sans-serif; color:black">I have provided my feedback on your review already
<a href="https://reviews.llvm.org/D57768">https://reviews.llvm.org/D57768</a> but I think the topics mainly belong here.</span></p>
<p><span style="font-family:"Calibri",sans-serif; color:black"> </span></p>
<p><span style="font-family:"Calibri",sans-serif; color:black">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.</span></p>
<p><span style="font-family:"Calibri",sans-serif; color:black"> </span></p>
<p><span style="font-family:"Calibri",sans-serif; color:black">Particularly, the following aspects require more attention:</span></p>
<ul type="disc">
<li class="x_MsoNormal" style="color:black"><span style="font-family:"Calibri",sans-serif">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?</span></li></ul>
<ul type="disc">
<li class="x_MsoNormal" style="color:black"><span style="font-family:"Calibri",sans-serif">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!</span></li></ul>
<ul type="disc">
<li class="x_MsoNormal" style="color:black"><span style="font-family:"Calibri",sans-serif">What is your solution for integration with SPIR-V and how does it relate to our previous discussions in October:
<a href="http://lists.llvm.org/pipermail/cfe-dev/2018-October/059974.html" target="_blank">
http://lists.llvm.org/pipermail/cfe-dev/2018-October/059974.html</a></span></li></ul>
<ul type="disc">
<li class="x_MsoNormal" style="color:black"><span style="font-family:"Calibri",sans-serif">Can you explain the purpose of
<a href="https://github.com/intel/llvm/tree/sycl/clang/lib/CodeGen/OclCxxRewrite" target="_blank">
https://github.com/intel/llvm/tree/sycl/clang/lib/CodeGen/OclCxxRewrite</a> that you are adding to Clang?</span></li></ul>
<p class="x_MsoNormal"><span class="x_transaction-comment"><span style="font-family:"Calibri",sans-serif; color:black">Cheers,</span></span><span style="font-family:"Calibri",sans-serif; color:black"></span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin-bottom:12.0pt"><span class="x_transaction-comment"><span style="font-family:"Calibri",sans-serif; color:black">Anastasia</span></span><span style="font-family:"Calibri",sans-serif; color:black"><br>
<br>
</span></p>
<div>
<div class="x_MsoNormal" style="text-align:center" align="center"><span style="font-family:"Calibri",sans-serif; color:black">
<hr width="98%" size="2" align="center">
</span></div>
<div id="x_divRplyFwdMsg">
<p class="x_MsoNormal"><b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">From:</span></b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black"> cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org">cfe-dev-bounces@lists.llvm.org</a>>
on behalf of Bader, Alexey via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
<b>Sent:</b> 30 January 2019 22:06<br>
<b>To:</b> David Airlie<br>
<b>Cc:</b> cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>)<br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Add SYCL programming model support.</span><span style="font-family:"Calibri",sans-serif; color:black">
</span></p>
<div>
<p class="x_MsoNormal"><span style="font-family:"Calibri",sans-serif; color:black"> </span></p>
</div>
</div>
<div>
<div>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">Hi Dave,<br>
<br>
Thanks for your comments.<br>
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.<br>
This approach should be aligned with existing implementation of address spaces for OpenCL C++.<br>
<br>
Thanks,<br>
Alexey<br>
<br>
-----Original Message-----<br>
From: David Airlie [<a href="mailto:airlied@redhat.com">mailto:airlied@redhat.com</a>]
<br>
Sent: Monday, January 28, 2019 9:45 PM<br>
To: Bader, Alexey <<a href="mailto:alexey.bader@intel.com">alexey.bader@intel.com</a>><br>
Cc: cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>) <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] [RFC] Add SYCL programming model support.<br>
<br>
On Sat, Jan 26, 2019 at 6:11 AM Bader, Alexey via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
><br>
><br>
> A short update: we uploaded SYCL compiler and runtime sources to the GitHub <a href="https://github.com/intel/llvm/tree/sycl">
https://github.com/intel/llvm/tree/sycl</a>.<br>
><br>
><br>
><br>
> Thanks to all who provided feedback and expressed interest in this project (mostly off the clang mailing list).<br>
><br>
> If there are no objections, we are going to start sending patches for review in a week or two.<br>
<br>
Hi Alexey,<br>
<br>
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:<br>
<br>
There seems to be some interaction or reliance on old address space behaviour,<br>
<br>
I don't think (maybe I'm wrong) that upstream will want to accept:<br>
[SYCL] Revert "[OpenCL] Enable address spaces for references in C++"<br>
or at least the OpenCL C++ people need to be talked to.<br>
<br>
Is there some more work that could be done in these to avoid the revert?<br>
[SYCL] Implement SYCL address-space rules.<br>
- do we have to use separate sycl address spaces as at all here btw?<br>
or are the opencl ones defined already not sufficient?<br>
[SYCL] Add SYCL-specific address spaces fixer pass.<br>
<br>
Dave.<br>
<br>
--------------------------------------------------------------------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park,<br>
17 Krylatskaya Str., Bldg 4, Moscow 121614,<br>
Russian Federation<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p><br>
--------------------------------------------------------------------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park, <br>
17 Krylatskaya Str., Bldg 4, Moscow 121614, <br>
Russian Federation</p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p>
</div>
</div>
</div>
</div>
</body>
</html>