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