<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">If I understand their proposal correctly, from the discussion Alexey linked to in <span class="" style="text-decoration: underline; -webkit-font-kerning: none;"><font color="#813a5f" class=""><a href="https://reviews.llvm.org/D80932#2073542" class="">https://reviews.llvm.org/D80932#2073542</a></font><font color="#453ccc" class=""><span style="caret-color: rgb(69, 60, 204);" class="">,</span></font></span> the primary motivation for their implementation — its main distinction from OpenCL’s approach -- is that they want to support address spaces in such a way that existing C++ files without any address space markings can still compile as is.<div class=""><br class=""></div><div class="">That definitely seems like a worthy goal if it could be properly accomplished. </div><div class=""><br class=""></div><div class="">Take, for instance, the "const" qualifier. Code which never uses it whatsoever still works by default; only when we start adding "const" into our code could we possibly start breaking other code. That is the ideal way to introduce a language feature: old code still works, but now people can opt in to the new stuff.</div><div class=""><br class=""></div><div class="">If instead const-ness had been implemented by allowing each type to be either "const" or (let’s say) "mutable" *or neither*, and what is more we implicitly added "mutable" when no such marking was provided to some *but not all* types, then the users would not have the option of ignoring it altogether, it would be a real headache.</div><div class=""><br class=""></div><div class="">This seems to be how OpenCL is implemented, as Alexey et al identify in the discussion linked above: certain VarDecl types get an implicit __private qualifier, but e.g. template argument types, and certain other types (they give another example beyond std::is_same which presents problems) get no such implicit qualifier, resulting in possible breakage in any code whose address spaces have not been closely considered.</div><div class=""><br class=""></div><div class="">Alexey et al's alternative to prevent this breakage, if I understand correctly, is to remove the type qualifier, and instead handle all address space semantics in CodeGen (I believe this is what you refer to as keeping the address space "flat"). </div><div class=""><br class=""></div><div class="">It seems to me that approach is not ideal, though, because </div><div class=""> a) it seems they would lose the type-checking benefits of implementing as a type qualifier (e.g. imagine if "const" qualifiers were removed and handled instead in CodeGen), and </div><div class=""> b) I think it really is important for the AST to maintain a clear representation of all target-independent semantics, including address spaces, so that users can easily reason about their code in AST matchers etc.</div><div class=""><br class=""></div><div class="">So the ideal, it seems to me, for everyone’s sake, would be for OpenCL qualifiers to behave more like "const" — there would be a default, a la "non-const", that is applied to all types not explicitly qualified, so that one could enable OpenCL mode and regular code would still work by default.</div><div class=""><div><br class=""></div><div>In reality though, I imagine this has all already been thought over thoroughly, and it has been determined it really is unavoidable to break standard C++ semantics in order to support address spaces; that there really is no default that could be inferred for arbitrary types like those used in template arguments. </div><div><br class=""></div><div>But perhaps it is worthwhile to think it through one more time, to question whether there may be some way to deduce type qualifiers properly in every case, because the issue that Alexey et al raise is a good one I think.</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 29, 2020, at 5:42 PM, Anastasia Stulova <<a href="mailto:Anastasia.Stulova@arm.com" class="">Anastasia.Stulova@arm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><div style="margin: 0px;" class="">> I am not well-versed in this, but just thinking about these as arbitrary type qualifiers: could the issue be simply that the implicitly-generated address space qualifiers are *only* being added to the types of VarDecls, rather than to *every* type, including pointee types, template argument types, etc.?</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">It is a little bit more complex than that. Most of the types used with objects in OpenCL will get an address space deduced including pointer types. This is because OpenCL is a language dialect for memory segmented architectures and the memory segments pose some limitations resulting in extra language rules. Clang strictly follows OpenCL language spec and I don't see any issue in the examples Alexey has referred to. If the types differ by address space is_same is expected to return false.<br class=""></div><div style="margin: 0px;" class="">What I struggle to understand how does this affects SYCL at all? The deduction of address spaces is guarded by OpenCL language mode and it is not set for SYCL as far as I am aware.</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">> If it did, I believe those examples would all compile, and code would only break when the user specified began specifying non-default address spaces</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">If I understand the design Alexey is proposing correctly the user-specified address spaces are cast to the default address spaces "hiddenly" and the AST always ends up to be in flat address space. This is why I don't see the address space as a good fit. However, I am not sure this is explained explicitly in the RFC, I might have remembered this from some other discussions.<br class=""></div></div><div id="appendonsend" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><br class=""></div><hr tabindex="-1" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline-block; width: 713.4375px;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""></span><div id="divRplyFwdMsg" dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><font face="Calibri, sans-serif" style="font-size: 11pt;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>David Rector <<a href="mailto:davrecthreads@gmail.com" class="">davrecthreads@gmail.com</a>><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>27 July 2020 22:32<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Bader, Alexey <<a href="mailto:alexey.bader@intel.com" class="">alexey.bader@intel.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>Anastasia Stulova <<a href="mailto:Anastasia.Stulova@arm.com" class="">Anastasia.Stulova@arm.com</a>>; cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>) <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>>; <a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a> <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>>; nd <<a href="mailto:nd@arm.com" class="">nd@arm.com</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [cfe-dev] [RFC] Re-use OpenCL address space attributes for SYCL</font><div class=""> </div></div><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; line-break: after-white-space;"><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">On Jul 27, 2020, at 12:18 PM, Bader, Alexey via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> > I don't think (2) deal with language semantics. I assume we both talking about</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> > the same case when variable declaration is not explicitly annotated with address</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> > space attribute. According to language semantics such objects are allocated in</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> > generic address space, but the problem is that most OpenCL implementations have</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> > problems with consuming SPIR-V files with global variables in generic address</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> > space. As an alternative to CodeGen changes we can consider handling this issue</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> > in SPIR-V translator tool.</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> I am not really a CodeGen expert, maybe it will be ok. I think it's better if you discuss</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> it with John McCall or someone who is more experienced with CodeGen architecture.</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> Why don't you just do regular address space deduction in Sema and then cast the</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> deduced address space to generic straight after? You already add similar casts for</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> pointers that are annotated with address spaces through the user code, right?</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">> This approach will probably allow to reuse the logic from OpenCL and simplify CodeGen.</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204); min-height: 14px;" class=""><span class="" style="-webkit-font-kerning: none;"> </span><br class="x_webkit-block-placeholder"></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);"><span class="" style="-webkit-font-kerning: none;">I don't see how it can be done without breaking C++ semantics demonstrated in</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(129, 58, 95);"><span class="" style="text-decoration: underline; -webkit-font-kerning: none;"><a href="https://reviews.llvm.org/D80932#2073542" class="">https://reviews.llvm.org/D80932#2073542</a></span><span class="" style="-webkit-font-kerning: none; color: rgb(69, 60, 204);">. </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;"><span class="" style="-webkit-font-kerning: none;"></span><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;">I am not well-versed in this, but just thinking about these as arbitrary type qualifiers: could the issue be simply that the implicitly-generated address space qualifiers are *only* being added to the types of VarDecls, rather than to *every* type, including pointee types, template argument types, etc.?</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;">I.e., referring to the examples linked to above: perhaps the problem is *not* that that OpenCL changes `<span class="" style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;">int var</span>` to `<span class="" style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;">__private int var</span>`, but rather that it does not *also* change `<span class="" style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;">int* ptr1 = &var</span>` to `<span class="" style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;">__private int* __private ptr1 = &var</span>` (or whatever the proper default qualifiers are) and `<span class="" style="font-stretch: normal; font-size: 10px; line-height: normal;">s</span><span class="" style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;">td::is_same<T, int></span>` to `<span class="" style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;">std::is_same<T, __private int></span>` when in OpenCL (or SYCL) mode.</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;">If it did, I believe those examples would all compile, and code would only break when the user specified began specifying non-default address spaces, i.e. when they actually used the feature in their code. In this way, the non-standard semantics could be represented in the AST without affecting the standard semantics.</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;">In any case that is the form of the ideal solution: sure, don’t break the standard C++ semantics, but also, try to keep a clear representation of any supported-but-non-standard semantics in the AST, I think.</div></div></div></blockquote></div><br class=""></div></body></html>