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