<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);">
<div style="margin:0px">> 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"><br>
</div>
<div style="margin:0px">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>
</div>
<div style="margin:0px">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"><br>
</div>
<div style="margin:0px">> 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"><br>
</div>
<div style="margin:0px">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>
</div>
</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> David Rector <davrecthreads@gmail.com><br>
<b>Sent:</b> 27 July 2020 22:32<br>
<b>To:</b> Bader, Alexey <alexey.bader@intel.com><br>
<b>Cc:</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>; nd <nd@arm.com><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Re-use OpenCL address space attributes for SYCL</font>
<div> </div>
</div>
<div class="" style="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="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="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="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="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="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="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="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="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="font-kerning:none">> </span></div>
<div class="" style="margin:0px; font-stretch:normal; line-height:normal; color:rgb(69,60,204)">
<span class="" style="font-kerning:none">> </span></div>
<div class="" style="margin:0px; font-stretch:normal; line-height:normal; color:rgb(69,60,204)">
<span class="" style="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="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="font-kerning:none">> </span></div>
<div class="" style="margin:0px; font-stretch:normal; line-height:normal; color:rgb(69,60,204)">
<span class="" style="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="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="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="font-kerning:none">> This approach will probably allow to reuse the logic from OpenCL and simplify CodeGen.</span></div>
<p class="" style="margin:0px; font-stretch:normal; line-height:normal; color:rgb(69,60,204); min-height:14px">
<span class="" style="font-kerning:none"> </span><br class="x_webkit-block-placeholder">
</p>
<div class="" style="margin:0px; font-stretch:normal; line-height:normal; color:rgb(69,60,204)">
<span class="" style="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; font-kerning:none"><a href="https://reviews.llvm.org/D80932#2073542" class="">https://reviews.llvm.org/D80932#2073542</a></span><span class="" style="font-kerning:none; color:#453ccc">. </span></div>
<div class="" style="margin:0px; font-stretch:normal; line-height:normal; min-height:14px">
<span class="" style="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>
</body>
</html>