<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
{mso-style-name:x_msonormal;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xmsonormal0, li.xmsonormal0, div.xmsonormal0
{mso-style-name:x_msonormal0;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xxmsonormal, li.xxmsonormal, div.xxmsonormal
{mso-style-name:x_xmsonormal;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xmsochpdefault, li.xmsochpdefault, div.xmsochpdefault
{mso-style-name:x_msochpdefault;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.xmsohyperlink
{mso-style-name:x_msohyperlink;
color:#0563C1;
text-decoration:underline;}
span.xmsohyperlinkfollowed
{mso-style-name:x_msohyperlinkfollowed;
color:#954F72;
text-decoration:underline;}
span.xemailstyle21
{mso-style-name:x_emailstyle21;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="RU" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > I don't think (2) deal with language semantics. I assume we both talking about<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > the same case when variable declaration is not explicitly annotated with address<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > space attribute. According to language semantics such objects are allocated in<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > generic address space, but the problem is that most OpenCL implementations have<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > problems with consuming SPIR-V files with global variables in generic address<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > space. As an alternative to CodeGen changes we can consider handling this issue<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > in SPIR-V translator tool.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> I am not really a CodeGen expert, maybe it will be ok. I think it's better if you discuss<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> it with John McCall or someone who is more experienced with CodeGen architecture.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> Why don't you just do regular address space deduction in Sema and then cast the<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> deduced address space to generic straight after? You already add similar casts for<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> pointers that are annotated with address spaces through the user code, right?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> This approach will probably allow to reuse the logic from OpenCL and simplify CodeGen.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I don't see how it can be done without breaking C++ semantics demonstrated in<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">https://reviews.llvm.org/D80932#2073542.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > This change is need to keep the types in LLVM IR consistent. Regular C++ user<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > code usually doesn't have address space annotations, so if memory references and<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > pointers are "generic". When allocation is done in named address space, we must<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > add address space cast to keep LLVM pointer types aligned.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> I feel that your design is slightly different to what address space attributes were intended<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> for. The address spaces were introduced for embedded C and other dialects where the<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> same logic applies. The address space is added into a type qualifer. This binds an object to<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> certain memory segments and therefore the only valid conversions for different addresses<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> are either using explicit casts or implicit conversions in operands of operations, similar to<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> regular qualifiers or arithmetic conversions. There are no unexpected address space<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> conversions from explicit address spaces to generic/default otherwise.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> It feels to me that what you actually need semantically is a flat memory. Then the<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> embedded C model is just overkill. I feel the address space attribute might just not be<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> a good conceptual fit for your design. Have you considered adding a new custom<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> attribute to annotate pointer variable classes or variables with memory segments<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> without propagating this into a type qualifier?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Yes. Originally we used separate attributes, but we replaced them with OpenCL<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">attributes. At some point we had OpenCL "parsed attribute representation" with<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">new semantic attributes - https://github.com/intel/llvm/pull/968/.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I can rebase the patch and upload it to Phabricator if it okay (and add new<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">parsed representation if needed).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> I imagine it would be pretty easy to implement in the frontend as you just need to propagate<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> this to IR. Then your middle-end passes can use this annotation to remap from<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> default/generic address space into any exact one. I think you can even achieve higher flexibility<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> by using such annotation only as some sort of a hint and allow an optimizer to choose alternative<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> memory regions if it can result in higher performance.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> > Feel free to join today's sync meeting at 9AM PT to have an online discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> Thanks, but sorry it was short notice. Also I think it's good to use LLVM channels so we can<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> keep everyone else in the loop and also record information for future reference during the<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> code review or other documentation purposes.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Agree. Our sync meetings are not intended to replace LLVM channels, but rather<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">supplement them. In some cases phone calls are more efficient than email chains.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">We keep notes from these syncs here:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">https://github.com/intel/llvm/wiki/SYCL-upstreaming-working-group-meeting-notes,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">so that information is also available for reference.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Alexey<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Anastasia Stulova <Anastasia.Stulova@arm.com>
<br>
<b>Sent:</b> Friday, July 24, 2020 6:20 PM<br>
<b>To:</b> Bader, Alexey <alexey.bader@intel.com>; cfe-dev (cfe-dev@lists.llvm.org) <cfe-dev@lists.llvm.org>; rjmccall@apple.com<br>
<b>Cc:</b> nd <nd@arm.com><br>
<b>Subject:</b> Re: [RFC] Re-use OpenCL address space attributes for SYCL<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> As SPIR-V doesn't allow casts between constant and generic pointers, SYCL<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">> implementation doesn't use OpenCL constant address space attribute. "const"<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> qualified "global" address space attribute is used instead.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">FYI in OpenCL C such conversions are disallowed and since address spaces are<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">preserved in AST, any such conversion in the source will be diagnosed and<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">rejected. Constant address space indicates a memory region where read-only<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">data are to be placed for efficient accesses, so it is not quite the same as global<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">memory.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> It's not "address spaces" per se, but how OpenCL mode implements them.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> Victor did a good job covering this question in this comment:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> </span><a href="https://reviews.llvm.org/D80932#2073542"><span lang="EN-US">https://reviews.llvm.org/D80932#2073542</span></a><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I have replied to Victor's comment: </span>
<a href="https://reviews.llvm.org/D80932#2074792"><span lang="EN-US">https://reviews.llvm.org/D80932#2074792</span></a><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> What languages do you think might be impacted if we enable this change<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> unconditionally? Are there modes other than OpenCL and SYCL targeting SPIR?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Yes, some toolchains use it for standard C and C++ compilations to create<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">libraries to run on GPU-like targets. Generally, we should not limit SPIR to<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">OpenCL or SYCL. Clang design is made flexible to allow multiple targets<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">to support multiple languages. We shouldn't come up with an implementation<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">that will limit choices for future development.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> I don't think (2) deal with language semantics. I assume we both talking about<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> the same case when variable declaration is not explicitly annotated with address<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> space attribute. According to language semantics such objects are allocated in<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> generic address space, but the problem is that most OpenCL implementations have<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> problems with consuming SPIR-V files with global variables in generic address<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> space. As an alternative to CodeGen changes we can consider handling this issue<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> in SPIR-V translator tool.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I am not really a CodeGen expert, maybe it will be ok. I think it's better if you discuss<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">it with John McCall or someone who is more experienced with CodeGen architecture.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Why don't you just do regular address space deduction in Sema and then cast the<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">deduced address space to generic straight after? You already add similar casts for<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">pointers that are annotated with address spaces through the user code, right?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">This approach will probably allow to reuse the logic from OpenCL and simplify CodeGen.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Alternatively, I imagine you could add a simple transformation pass to remap address<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">spaces If you move this logic into the translator then I guess your compilation<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">will only work for SPIR-V?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> This change is need to keep the types in LLVM IR consistent. Regular C++ user<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> code usually doesn't have address space annotations, so if memory references and<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> pointers are "generic". When allocation is done in named address space, we must<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> add address space cast to keep LLVM pointer types aligned.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I feel that your design is slightly different to what address space attributes were intended<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">for. The address spaces were introduced for embedded C and other dialects where the<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">same logic applies. The address space is added into a type qualifer. This binds an object to<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">certain memory segments and therefore the only valid conversions for different addresses<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">are either using explicit casts or implicit conversions in operands of operations, similar to<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">regular qualifiers or arithmetic conversions. There are no unexpected address space<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">conversions from explicit address spaces to generic/default otherwise.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">It feels to me that what you actually need semantically is a flat memory. Then the<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">embedded C model is just overkill. I feel the address space attribute might just not be<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">a good conceptual fit for your design. Have you considered adding a new custom<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">attribute to annotate pointer variable classes or variables with memory segments<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">without propagating this into a type qualifier?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I imagine it would be pretty easy to implement in the frontend as you just need to propagate<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">this to IR. Then your middle-end passes can use this annotation to remap from<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">default/generic address space into any exact one. I think you can even achieve higher flexibility<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">by using such annotation only as some sort of a hint and allow an optimizer to choose alternative<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">memory regions if it can result in higher performance.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> Feel free to join today's sync meeting at 9AM PT to have an online discussion.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Thanks, but sorry it was short notice. Also I think it's good to use LLVM channels so we can<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">keep everyone else in the loop and also record information for future reference during the<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US">code review or other documentation purposes.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span lang="EN-US" style="color:black">From:</span></b><span lang="EN-US" style="color:black"> Bader, Alexey <</span><a href="mailto:alexey.bader@intel.com"><span lang="EN-US">alexey.bader@intel.com</span></a><span lang="EN-US" style="color:black">><br>
<b>Sent:</b> 20 July 2020 13:22<br>
<b>To:</b> Anastasia Stulova <</span><a href="mailto:Anastasia.Stulova@arm.com"><span lang="EN-US">Anastasia.Stulova@arm.com</span></a><span lang="EN-US" style="color:black">>; cfe-dev (</span><a href="mailto:cfe-dev@lists.llvm.org"><span lang="EN-US">cfe-dev@lists.llvm.org</span></a><span lang="EN-US" style="color:black">)
<</span><a href="mailto:cfe-dev@lists.llvm.org"><span lang="EN-US">cfe-dev@lists.llvm.org</span></a><span lang="EN-US" style="color:black">>;
</span><a href="mailto:rjmccall@apple.com"><span lang="EN-US">rjmccall@apple.com</span></a><span lang="EN-US" style="color:black"> <</span><a href="mailto:rjmccall@apple.com"><span lang="EN-US">rjmccall@apple.com</span></a><span lang="EN-US" style="color:black">><br>
<b>Cc:</b> nd <</span><a href="mailto:nd@arm.com"><span lang="EN-US">nd@arm.com</span></a><span lang="EN-US" style="color:black">><br>
<b>Subject:</b> RE: [RFC] Re-use OpenCL address space attributes for SYCL</span><span lang="EN-US">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="xmsonormal"><span lang="EN-US">Hi Anastasia,<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Sorry for the delay.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > The main difference with OpenCL mode is that SYCL<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > mode (similar to other single-source GPU programming modes like<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > OpenMP/CUDA/HIP)<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > keeps "default" address space for the declaration without address space<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > attribute annotations.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> Just FYI in C++ mode, Clang implements default/generic address space as<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> specified in embedded C (ISO/IEC TR 18037) s5.1 - 5.3.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> "When not specified otherwise, objects are allocated by default in a generic<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> address space, which corresponds to the single address space of ISO/IEC<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> 9899:1999."<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> "Objects are allocated in one or more address spaces. A unique generic address<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> space always exists. Every address space other than the generic one has a unique<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> name in the form of an identifier. Address spaces other than the generic one are<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> called named address spaces. An object is always completely allocated into at<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> least one address space. Unless otherwise specified, objects are allocated in<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> the generic address space."<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> It feels to me this is the model you intend to follow?
<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">After reading the document I don't see major conflicts with our SYCL<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">implementation.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> If you use OpenCL address<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> space attributes outside of OpenCL mode there is limited logic that you will<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> inherit. For example deduction of address spaces wouldn't work but conversions<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> or generation to IR should work fine. It generally sounds like a viable approach<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> but OpenCL however used Default (no address space) as private AS for a very long<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> time and there are still a number of places where this assumption is inherent in<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> the implementation. This is not entirely strange as Default is use by many<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> languages for automatic storage anyway. My worry is there could be difficulties<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> in reusing the OpenCL address space model due to this.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> Btw can you elaborate on your implementation of constant addr space?<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">As SPIR-V doesn't allow casts between constant and generic pointers, SYCL<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">implementation doesn't use OpenCL constant address space attribute. "const"<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">qualified "global" address space attribute is used instead.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > This keeps the code shared between the host and device<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > semantically-correct for both compilers: regular C++ host compiler and SYCL<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > compiler.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> Sorry perhaps I am not following this thought but can you explain how<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> address spaces make code semantically incorrect?<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">It's not "address spaces" per se, but how OpenCL mode implements them.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Victor did a good job covering this question in this comment:<o:p></o:p></span></p>
<p class="xmsonormal"><a href="https://reviews.llvm.org/D80932#2073542"><span lang="EN-US">https://reviews.llvm.org/D80932#2073542</span></a><span lang="EN-US"><o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Example form this comment of valid C++ function, which is not valid in OpenCL<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">mode:<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">```c++<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">template<typename T1, typename T2><o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">struct is_same {<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> static constexpr int value = 0;<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">};<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">template<typename T><o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">struct is_same<T, T> {<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> static constexpr int value = 1;<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">};<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">void foo(int p) {<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> static_assert(is_same<decltype(p), int>::value, "int is not an int?"); // Fails: p is '__private int' != 'int'<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> static_assert(is_same<decltype(&p), int*>::value, "int* is not an int*?"); // Fails: p is '__private int*' != '__generic int*'<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">}<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">```<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > To make all pointers without an explicit address space qualifier to be<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > pointers<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > in generic address space, we updated SPIR target address space map, which<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > currently maps default pointers to "private" address space.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> The address space map in Clang is not specific to pointer types. How do you<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> make it work for pointers only?<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">I don't think we did anything specific to apply this change to pointers only.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Pointers provided here as an example to demonstrate the impact of the change in<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">LLVM IR representation for SPIR target.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > We made this change<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > specific to SYCL by adding SYCL environment component to the Triple to avoid<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > impact on other modes targeting SPIR target (e.g. OpenCL). We would be glad to<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > see get a feedback from the community if changing this mapping is applicable<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > for all the modes and additional specialization can be avoided (e.g.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > [AMDGPU](</span><a href="https://github.com/llvm/llvm-project/blob/master/clang/lib/Basic/Targets/AMDGPU.cpp#L329"><span lang="EN-US">https://github.com/llvm/llvm-project/blob/master/clang/lib/Basic/Targets/AMDGPU.cpp#L329</span></a><span lang="EN-US">)<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > maps default to "generic" address space with a couple of exceptions).<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> Ok, does it mean that you map Default address space to OpenCL generic?<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> Please note that Default address space is used outside of OpenCL for all<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> other languages so remapping this unconditionally will have a wider impact.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Current implementation applies different mapping only when "sycldevice"<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">environment is set in target triple.<o:p></o:p></span></p>
<p class="xmsonormal"><a href="https://github.com/bader/llvm/pull/18/files#diff-d62fb2e1d8c597ce59fd10e018f6fb77R61"><span lang="EN-US">https://github.com/bader/llvm/pull/18/files#diff-d62fb2e1d8c597ce59fd10e018f6fb77R61</span></a><span lang="EN-US"><o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">What languages do you think might be impacted if we enable this change<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">unconditionally? Are there modes other than OpenCL and SYCL targeting SPIR?<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > There are a few cases when CodeGen assigns non-default address space:<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > 1. For declaration explicitly annotated with address space attribute<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> This is generally how CodeGen works mapping language address spaces to target<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> address spaces. Is there something different you do here for SYCL?<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">No.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > 2. Variables with static storage duration and string literals are allocated in<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > global address space unless specific address space it specified.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > 3. Variables with automatic storage durations are allocated in private address<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > space. It's current compiler behavior and it doesn't require additional<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > changes.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> We already have this logic for OpenCL in Sema. I am not an expert in CodeGen but<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> I believe its primary task is to map language constructs onto the target specific IR<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> i.e. map from AST into IR. However, you are making it dial with language semantic<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> instead i.e. add missing AST logic such as address space attribute. I believe there<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> are good reasons to have layering architecture that separates various concerns.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> What drives your decision for moving this logic into CodeGen?<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">I don't think (2) deal with language semantics. I assume we both talking about<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">the same case when variable declaration is not explicitly annotated with address<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">space attribute. According to language semantics such objects are allocated in<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">generic address space, but the problem is that most OpenCL implementations have<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">problems with consuming SPIR-V files with global variables in generic address<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">space. As an alternative to CodeGen changes we can consider handling this issue<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">in SPIR-V translator tool.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > For (2) and (3) cases, once "default" pointer to such variable is obtained, it<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > is immediately addrspacecast'ed to generic, because a user does not (and<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> > should not) specify address space for pointers in source code.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> Can you explain why you need this cast?
<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">This change is need to keep the types in LLVM IR consistent. Regular C++ user<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">code usually doesn't have address space annotations, so if memory references and<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">pointers are "generic". When allocation is done in named address space, we must<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">add address space cast to keep LLVM pointer types aligned.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> Can user not specify address spaces using<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> pointer classes that map into address space attributed types i.e. ending up with<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">> pointer with address spaces originating from the user code?<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Yes.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Feel free to join today's sync meeting at 9AM PT to have an online discussion.<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Thanks,<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US">Alexey<o:p></o:p></span></p>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="xmsonormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Anastasia Stulova <</span><a href="mailto:Anastasia.Stulova@arm.com"><span lang="EN-US">Anastasia.Stulova@arm.com</span></a><span lang="EN-US">>
<br>
<b>Sent:</b> Thursday, July 9, 2020 2:51 PM<br>
<b>To:</b> Bader, Alexey <</span><a href="mailto:alexey.bader@intel.com"><span lang="EN-US">alexey.bader@intel.com</span></a><span lang="EN-US">>; cfe-dev (</span><a href="mailto:cfe-dev@lists.llvm.org"><span lang="EN-US">cfe-dev@lists.llvm.org</span></a><span lang="EN-US">)
<</span><a href="mailto:cfe-dev@lists.llvm.org"><span lang="EN-US">cfe-dev@lists.llvm.org</span></a><span lang="EN-US">>;
</span><a href="mailto:rjmccall@apple.com"><span lang="EN-US">rjmccall@apple.com</span></a><span lang="EN-US"><br>
<b>Cc:</b> nd <</span><a href="mailto:nd@arm.com"><span lang="EN-US">nd@arm.com</span></a><span lang="EN-US">><br>
<b>Subject:</b> Re: [RFC] Re-use OpenCL address space attributes for SYCL<o:p></o:p></span></p>
</div>
</div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<div>
<p class="xmsonormal"><span lang="EN-US">Hi Alexey,<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">Thanks for the clarification.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> SYCL compiler re-use generic support for these attributes as is and modifies<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> Sema and CodeGen libraries.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">Can you elaborate on your modifications in Sema and CodeGen, please?<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> The main difference with OpenCL mode is that SYCL<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> mode (similar to other single-source GPU programming modes like<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> OpenMP/CUDA/HIP)<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> keeps "default" address space for the declaration without address space<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> attribute annotations.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">Just FYI in C++ mode, Clang implements default/generic address space as<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">specified in embedded C (ISO/IEC TR 18037) s5.1 - 5.3.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">"When not specified otherwise, objects are allocated by default in a generic<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">address space, which corresponds to the single address space of ISO/IEC<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">9899:1999."<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">"Objects are allocated in one or more address spaces. A unique generic address<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">space always exists. Every address space other than the generic one has a unique<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">name in the form of an identifier. Address spaces other than the generic one are<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">called named address spaces. An object is always completely allocated into at<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">least one address space. Unless otherwise specified, objects are allocated in<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">the generic address space."<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">It feels to me this is the model you intend to follow? If you use OpenCL address<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">space attributes outside of OpenCL mode there is limited logic that you will<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">inherit. For example deduction of address spaces wouldn't work but conversions<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">or generation to IR should work fine. It generally sounds like a viable approach<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">but OpenCL however used Default (no address space) as private AS for a very long<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">time and there are still a number of places where this assumption is inherent in<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">the implementation. This is not entirely strange as Default is use by many<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">languages for automatic storage anyway. My worry is there could be difficulties<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">in reusing the OpenCL address space model due to this.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">Btw can you elaborate on your implementation of constant addr space?<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> This keeps the code shared between the host and device<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> semantically-correct for both compilers: regular C++ host compiler and SYCL<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> compiler.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">Sorry perhaps I am not following this thought but can you explain how<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">address spaces make code semantically incorrect?<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> To make all pointers without an explicit address space qualifier to be<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> pointers<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> in generic address space, we updated SPIR target address space map, which<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> currently maps default pointers to "private" address space.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">The address space map in Clang is not specific to pointer types. How do you<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">make it work for pointers only?<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> We made this change<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> specific to SYCL by adding SYCL environment component to the Triple to avoid<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> impact on other modes targeting SPIR target (e.g. OpenCL). We would be glad to<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> see get a feedback from the community if changing this mapping is applicable<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> for all the modes and additional specialization can be avoided (e.g.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> [AMDGPU](</span><a href="https://github.com/llvm/llvm-project/blob/master/clang/lib/Basic/Targets/AMDGPU.cpp#L329"><span lang="EN-US">https://github.com/llvm/llvm-project/blob/master/clang/lib/Basic/Targets/AMDGPU.cpp#L329</span></a><span lang="EN-US">)<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> maps default to "generic" address space with a couple of exceptions).<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">Ok, does it mean that you map Default address space to OpenCL generic?<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">Please note that Default address space is used outside of OpenCL for all<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">other languages so remapping this unconditionally will have a wider impact.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> There are a few cases when CodeGen assigns non-default address space:<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> 1. For declaration explicitly annotated with address space attribute<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">This is generally how CodeGen works mapping language address spaces to target<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">address spaces. Is there something different you do here for SYCL?<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> 2. Variables with static storage duration and string literals are allocated in<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> global address space unless specific address space it specified.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> 3. Variables with automatic storage durations are allocated in private address<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> space. It's current compiler behavior and it doesn't require additional<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> changes.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">We already have this logic for OpenCL in Sema. I am not an expert in CodeGen but<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">I believe its primary task is to map language constructs onto the target specific IR<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">i.e. map from AST into IR. However, you are making it dial with language semantic<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">instead i.e. add missing AST logic such as address space attribute. I believe there<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">are good reasons to have layering architecture that separates various concerns.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">What drives your decision for moving this logic into CodeGen?<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> For (2) and (3) cases, once "default" pointer to such variable is obtained, it<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> is immediately addrspacecast'ed to generic, because a user does not (and<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">> should not) specify address space for pointers in source code.<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">Can you explain why you need this cast? Can user not specify address spaces using<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">pointer classes that map into address space attributed types i.e. ending up with<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US">pointer with address spaces originating from the user code?<o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="xmsonormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="xmsonormal">Anastasia<o:p></o:p></p>
</div>
<div>
<p class="xmsonormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="xmsonormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="x_divRplyFwdMsg">
<p class="xmsonormal"><b><span lang="EN-US" style="color:black">From:</span></b><span lang="EN-US" style="color:black"> Bader, Alexey <</span><a href="mailto:alexey.bader@intel.com"><span lang="EN-US">alexey.bader@intel.com</span></a><span lang="EN-US" style="color:black">><br>
<b>Sent:</b> 26 June 2020 13:04<br>
<b>To:</b> cfe-dev (</span><a href="mailto:cfe-dev@lists.llvm.org"><span lang="EN-US">cfe-dev@lists.llvm.org</span></a><span lang="EN-US" style="color:black">) <</span><a href="mailto:cfe-dev@lists.llvm.org"><span lang="EN-US">cfe-dev@lists.llvm.org</span></a><span lang="EN-US" style="color:black">>;
Anastasia Stulova <</span><a href="mailto:Anastasia.Stulova@arm.com"><span lang="EN-US">Anastasia.Stulova@arm.com</span></a><span lang="EN-US" style="color:black">>;
</span><a href="mailto:rjmccall@apple.com"><span lang="EN-US">rjmccall@apple.com</span></a><span lang="EN-US" style="color:black"> <</span><a href="mailto:rjmccall@apple.com"><span lang="EN-US">rjmccall@apple.com</span></a><span lang="EN-US" style="color:black">><br>
<b>Subject:</b> [RFC] Re-use OpenCL address space attributes for SYCL</span><span lang="EN-US">
<o:p></o:p></span></p>
<div>
<p class="xmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="xxmsonormal"><span lang="EN-US">Hi,<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">We would like to re-use OpenCL address space attributes for SYCL to target<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">SPIR-V format and enable efficient memory access on GPUs.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">```c++<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> __attribute__((opencl_global))<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> __attribute__((opencl_local))<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> __attribute__((opencl_private))<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">```<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">The first patch enabling conversion between pointers annotated with OpenCL<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">address space attribute and "default" pointers is being reviewed here<o:p></o:p></span></p>
<p class="xxmsonormal"><a href="https://reviews.llvm.org/D80932"><span lang="EN-US">https://reviews.llvm.org/D80932</span></a><span lang="EN-US">.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">Before moving further with the implementation we would like to discuss two<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">questions raised in review comments (</span><a href="https://reviews.llvm.org/D80932#2085848"><span lang="EN-US">https://reviews.llvm.org/D80932#2085848</span></a><span lang="EN-US">).<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><b><span lang="EN-US">## Using attributes to annotate memory allocations</span></b><span lang="EN-US"><o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">Introduction section of SYCL-1.2.1 specification describes multiple compilation<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">flows intended by the design:<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> SYCL is designed to allow a compilation flow where the source file is passed<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> through multiple different compilers, including a standard C++ host compiler<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> of the developer’s choice, and where the resulting application combines the<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> results of these compilation passes. This is distinct from a single-source<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> flow that might use language extensions that preclude the use of a standard<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> host compiler. The SYCL standard does not preclude the use of a single<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> compiler flow, but is designed to not require it.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> The advantages of this design are two-fold. First, it offers better<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> integration with existing tool chains. An application that already builds<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> using a chosen compiler can continue to do so when SYCL code is added. Using<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> the SYCL tools on a source file within a project will both compile for an<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> OpenCL device and let the same source file be compiled using the same host<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> compiler that the rest of the project is compiled with. Linking and library<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> relationships are unaffected. This design simplifies porting of pre-existing<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> applications to SYCL. Second, the design allows the optimal compiler to be<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> chosen for each device where different vendors may provide optimized<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> tool-chains.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> SYCL is designed to be as close to standard C++ as possible. In practice,<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> this means that as long as no dependence is created on SYCL’s integration<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> with OpenCL, a standard C++ compiler can compile the SYCL programs and they<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> will run correctly on host CPU. Any use of specialized low-level features<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> can be masked using the C preprocessor in the same way that<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> compiler-specific intrinsics may be hidden to ensure portability between<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">> different host compilers.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">Following this approach, SYCL uses C++ templates to represent pointers to<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">disjoint memory regions on an accelerator to enable compilation with standard<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">C++ toolchain and SYCL compiler toolchain.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">For instance:<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">```c++<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">// CPU/host implementation<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">template <typename T, address_space AS> class multi_ptr {<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> T *data; // ignore address space parameter on CPU<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> public:<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> T *get_pointer() { return data; }<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">}<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">// check that SYCL mode is ON and we can use non-standard annotations<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">#if defined(__SYCL_DEVICE_ONLY__)<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">// GPU/accelerator implementation<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">template <typename T, address_space AS> class multi_ptr {<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> // GetAnnotatedPointer<T, global>::type == "__attribute__((opencl_global)) T"<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> using pointer_t = typename GetAnnotatedPointer<T, AS>::type *;<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> pointer_t data;<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> public:<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> pointer_t get_pointer() { return data; }<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">}<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">#endif<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">```<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">User can use `multi_ptr` class as regular user-defined type in regular C++ code:<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">```c++<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">int *UserFunc(multi_ptr<int, global> ptr) {<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> /// ...<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> return ptr.get_pointer();<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">}<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">```<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">Depending on the compiler mode `multi_ptr` will either annotate internal data<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">with address space attribute or not.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><b><span lang="EN-US">## Implementation details</span></b><span lang="EN-US"><o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">OpenCL attributes are handled by Parser in all modes. OpenCL mode has specific<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">logic in Sema and CodeGen components for these attributes.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">SYCL compiler re-use generic support for these attributes as is and modifies<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">Sema and CodeGen libraries. The main difference with OpenCL mode is that SYCL<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">mode (similar to other single-source GPU programming modes like OpenMP/CUDA/HIP)<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">keeps "default" address space for the declaration without address space<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">attribute annotations. This keeps the code shared between the host and device<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">semantically-correct for both compilers: regular C++ host compiler and SYCL<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">compiler.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">To make all pointers without an explicit address space qualifier to be pointers<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">in generic address space, we updated SPIR target address space map, which<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">currently maps default pointers to "private" address space. We made this change<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">specific to SYCL by adding SYCL environment component to the Triple to avoid<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">impact on other modes targeting SPIR target (e.g. OpenCL). We would be glad to<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">see get a feedback from the community if changing this mapping is applicable for<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">all the modes and additional specialization can be avoided (e.g.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">[AMDGPU](</span><a href="https://github.com/llvm/llvm-project/blob/master/clang/lib/Basic/Targets/AMDGPU.cpp#L329"><span lang="EN-US">https://github.com/llvm/llvm-project/blob/master/clang/lib/Basic/Targets/AMDGPU.cpp#L329</span></a><span lang="EN-US">)<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">maps default to "generic" address space with a couple of exceptions).<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">There are a few cases when CodeGen assigns non-default address space:<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">1. For declaration explicitly annotated with address space attribute<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">2. Variables with static storage duration and string literals are allocated in<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> global address space unless specific address space it specified.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">3. Variables with automatic storage durations are allocated in private address<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> space. It's current compiler behavior and it doesn't require additional<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> changes.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">For (2) and (3) cases, once "default" pointer to such variable is obtained, it<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">is immediately addrspacecast'ed to generic, because a user does not (and should<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">not) specify address space for pointers in source code.<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">A draft patch containing complete change-set is available <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">[here](</span><a href="https://github.com/bader/llvm/pull/18/"><span lang="EN-US">https://github.com/bader/llvm/pull/18/</span></a><span lang="EN-US">).<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US">Does this approach seem reasonable?<o:p></o:p></span></p>
<p class="xxmsonormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="xxmsonormal">Thanks,<o:p></o:p></p>
<p class="xxmsonormal">Alexey<o:p></o:p></p>
<p class="xxmsonormal"> <o:p></o:p></p>
<p class="xxmsonormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>