<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" dir="ltr" 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">
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<div style="color:rgb(0,0,0)">
<div>
<div dir="ltr">
<div class="x_gmail_quote">
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_8439034347364691149divtagdefaultwrapper" dir="ltr" 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">
<div style="color:rgb(0,0,0)">
<div id="x_gmail-m_8439034347364691149divRplyFwdMsg" dir="ltr">
<div> </div>
</div>
<div lang="EN-US">
<div class="x_gmail-m_8439034347364691149x_WordSection1">
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>>> Let me check that I understand this question correctly. Are you asking about implementation of pointer classes representing pointers to different address spaces?</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>> 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.</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">One of the goals of SYCL design is to allow developers to compile and run SYCL code even if the compiler toolchain doesn’t support acceleration through OpenCL.</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This is somehow very unfortunate because the specification for SYCL is titled "SYCL integrates OpenCL devices with modern C++". That implies that it targets OpenCL explicitly. If there is shift of focus potentially some update is needed to avoid confusions.
However, I believe this is still a side goal of SYCL? There are plenty of other parallel languages that don't target OpenCL. What is the benefit of using SYCL if there is no OpenCL available? Anyway, this is probably not the discussion that belongs here, but
since we are touching this topic I feel somehow unfortunate that we have to pay the price in the compiler implementation to working around something that doesn't seem to be a primary use case. :(<br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_8439034347364691149divtagdefaultwrapper" dir="ltr" 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">
<div style="color:rgb(0,0,0)">
<div lang="EN-US">
<div class="x_gmail-m_8439034347364691149x_WordSection1">
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">Unfortunately "OpenCL address spaces" is not C++ standard feature (yet :)), so if we expose them to the user, the program written with these extensions will not be supported by other C++ compiler like GCC
or MSVC. Using standard API allows us to utilize all sorts of extensions for API implementation and emulate them with standard C++ if extensions are not available.</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>So how do you plan to emulate this it in GCC or MSVC and why can't we use the same pure C++ library based approach in Clang?<br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_8439034347364691149divtagdefaultwrapper" dir="ltr" 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">
<div style="color:rgb(0,0,0)">
<div lang="EN-US">
<div class="x_gmail-m_8439034347364691149x_WordSection1">
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">It is plausible to assume that it should be easier for C++ developers to adopt new functionality through standard C++ concepts like class/function rather than through language extensions.</p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><br>
</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>My personal opinion is that learning library APIs or a set of new keywords is approximately the same especially for those that already mastered the complexity of C++. However, I have to say understanding the extra "magic" behind what appears to be regular
C++ classes some developers might find somewhat counter-intuitive.</div>
<div><br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_8439034347364691149divtagdefaultwrapper" dir="ltr" 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">
<div style="color:rgb(0,0,0)">
<div lang="EN-US">
<div class="x_gmail-m_8439034347364691149x_WordSection1">
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>> 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.
</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i><a href="https://github.com/intel/llvm/commit/03354a29868b79a30e6fb2c8311bb409a8cc2346#diff-811283eaa55fa65f65713fdd7ecaf4aa" target="_blank">https://github.com/intel/llvm/commit/03354a29868b79a30e6fb2c8311bb409a8cc2346#diff-811283eaa55fa65f65713fdd7ecaf4aa</a></i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">We switched to using "function attributes" in later commit
<a href="https://github.com/llvm/llvm-project/commit/120b4b509d758e27c17111eaa0398b4cecf7575a" target="_blank">
https://github.com/llvm/llvm-project/commit/120b4b509d758e27c17111eaa0398b4cecf7575a</a>. Basically SYCL runtime marks functions supposed to be offloaded to the target device with special function attribute (similar to OpenCL `kernel` attribute) and compiler
doesn't rely on particular library function names.</p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">One the other hand there are other places where similar dependencies exist. For instance, typical SYCL kernel function captures "accessor" parameters, which provides "view" on the data accessed the by the
device code. This accessor class contains a pointer this data and it's initialized on the host. To pass C++ class with a pointer to memory from the host to accelerator we need either:</p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">1. system to support some sort of virtual memory, so the target know how to handle host pointers</p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">2. some cooperation between the compiler and runtime on converting host pointers to target pointers</p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">As OpenCL implementation is not guaranteed to support option (1), we implemented option (2) and current implementation relies on SYCL class method names from the standard, but I guess this might be not
the best option. I am going to send a separate email to discuss this topic in more details.</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, I think an RFC on that is a good idea! We can potentially brainstorm with the rest of Clang developer and find a more salable and elegant solution rather than trying to emulate libraries behavior in the compiler. Besides breaking conventional libraries
design approach it incurs the overhead of costly string operations that in some places might have to be performed on every function call or declaration. I am also wondering if you have made any benchmarking of that. Even if it will be gated away from the rest
of the code it will still have to be maintained by others if common functionality is required. It can potentially also impact the Clang test suite time as well.</div>
<div><br>
</div>
<div>I think it would be good to have a list of those with some information of how they impact the parser. Hopefully we can reuse attributes or Clang builtin function mechanism for most of those.
<br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_8439034347364691149divtagdefaultwrapper" dir="ltr" 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">
<div style="color:rgb(0,0,0)">
<div lang="EN-US">
<div class="x_gmail-m_8439034347364691149x_WordSection1">
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>>> 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++.
</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>>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.</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">By "library based language features" you mean OpenCL specific data types. Right? If so, I think SYCL can re-use OpenCL C++ implementation by outlining "device code" from the single source and then treating
it as a OpenCL C++ program.</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, it's address spaces and data types mainly. We do plan to port some of new useful C++ libraries such as for example an array container. I think you should be able to reuse OpenCL native types/contracts for SYCL. It would be good to have a list however
to see how we can make best use of available functionality rather than duplicating similar features.<br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_8439034347364691149divtagdefaultwrapper" dir="ltr" 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">
<div style="color:rgb(0,0,0)">
<div lang="EN-US">
<div class="x_gmail-m_8439034347364691149x_WordSection1"><span lang="RU"> </span>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">I agree that SPIR-V support must be added not only for SYCL, but for OpenCL C++ too, as it's necessary part of OpenCL C++ compiler toolchain. I think other extensions/APIs might benefit from having native
SPIR-V support in LLVM (e.g. OpenMP/Vulkan).</p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">IIRC, the latest discussion ended with a request to build a community around the translator tool. IMHO, we have the community for a long time, but it's not vocal in the LLVM mailing lists and not visible
for LLVM community (I can blame myself too <span style="font-family:Wingdings">J</span>). I'm aware of multiple projects using this tool to offload computation to OpenCL accelerators and I'll try to provide the evidence in dedicated mailing thread.</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Cool, perhaps it's time to revisit this! I would suggest another RFC!<br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_8439034347364691149divtagdefaultwrapper" dir="ltr" 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">
<div style="color:rgb(0,0,0)">
<div lang="EN-US">
<div class="x_gmail-m_8439034347364691149x_WordSection1">
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>>> 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”.</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>>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?</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">Sure. OpenCL C approach for built-in functions is "Itanuim C++ ABI mangled names in global name space". This doesn't work for OpenCL C++/SYCL as these built-ins collide with user functions. We re-use existing
prototype to speed-up SYCL development, but according to my understanding it might violate some LLVM guidelines for extending LLVM IR.</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Was that not the same for OpenCL C? All BIFs could be re-declared in the user code. The same applies to C/C++ standard libraries. Perhaps, I am not yet clear what problem you are trying to solve with this. I think it's something SPIR-V related? Just as
a side note, LLVM only has one intermediate format that is its IR. Any design should take this into account. The implementation of any fronted feature should work such that generic IR is generated. It's responsibility of the consumer to lower this down to
the required format.</div>
<div><br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_8439034347364691149divtagdefaultwrapper" dir="ltr" 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">
<div style="color:rgb(0,0,0)">
<div lang="EN-US">
<div class="x_gmail-m_8439034347364691149x_WordSection1">
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>>> Anyway <a href="https://reviews.llvm.org/D57768" target="_blank">
https://reviews.llvm.org/D57768</a> is not related to these topics and it’s aligned with existing CUDA/OpenMP functionality.</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"><i>>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?</i></p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText"> </p>
<p class="x_gmail-m_8439034347364691149x_MsoPlainText">I'll write a design document to provide more details on how things are done.</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Sure I think this is really great way moving forward! I would specifically be interested in where and how OpenCL implementation can be re-used in SYCL to make sure we can work together towards as much common infrastructure as possible. As suggested before,
you might want to cover other related areas like CUDA/OpenMP (if any common functionality exist on a single source concept side) that can be assessed by other communities.</div>
<div><br>
</div>
<div>Thanks for clarifications btw! They helped a lot!</div>
<div><br>
</div>
<div>Anastasia</div>
<div><br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr"><br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
</body>
</html>