<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=""><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">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 style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> > I don't think (2) deal with language semantics. I assume we both talking about</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> > the same case when variable declaration is not explicitly annotated with address</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> > space attribute. According to language semantics such objects are allocated in</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> > generic address space, but the problem is that most OpenCL implementations have</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> > problems with consuming SPIR-V files with global variables in generic address</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> > space. As an alternative to CodeGen changes we can consider handling this issue</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> > in SPIR-V translator tool.</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> </span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> </span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> I am not really a CodeGen expert, maybe it will be ok. I think it's better if you discuss</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> it with John McCall or someone who is more experienced with CodeGen architecture.</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> </span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> Why don't you just do regular address space deduction in Sema and then cast the</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> deduced address space to generic straight after? You already add similar casts for</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> pointers that are annotated with address spaces through the user code, right?</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">> This approach will probably allow to reuse the logic from OpenCL and simplify CodeGen.</span></div><p style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204); min-height: 14px;" class=""><span style="font-kerning: none" class=""> </span><br class="webkit-block-placeholder"></p><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(69, 60, 204);" class=""><span style="font-kerning: none" class="">I don't see how it can be done without breaking C++ semantics demonstrated in</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(129, 58, 95);" class=""><span style="text-decoration: underline ; font-kerning: none" class=""><a href="https://reviews.llvm.org/D80932#2073542" class="">https://reviews.llvm.org/D80932#2073542</a></span><span style="font-kerning: none; color: #453ccc" class="">. </span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><span style="font-kerning: none" class=""></span><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" 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; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">I.e., referring to the examples linked to above: perhaps the problem is *not* that that OpenCL changes `<span style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;" class="">int var</span>` to `<span style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;" class="">__private int var</span>`, but rather that it does not *also* change `<span style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;" class="">int* ptr1 = &var</span>` to `<span style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;" class="">__private int* __private ptr1 = &var</span>` (or whatever the proper default qualifiers are) and `<span style="font-stretch: normal; font-size: 10px; line-height: normal;" class="">s</span><span style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;" class="">td::is_same<T, int></span>` to `<span style="font-stretch: normal; font-size: 10px; line-height: normal; font-family: Menlo;" class="">std::is_same<T, __private int></span>` when in OpenCL (or SYCL) mode.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" 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, 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 style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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></body></html>