<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>Just to make it clear - C++ libraries or any existing C++ code doesn't</div>
<div>necessarily stop to compile if address space attributes are being used. It only</div>
<div>fails on illegal use of address spaces defined by Embedded C spec from where</div>
<div>the implementation originates.<br>
</div>
<div><br>
</div>
<div>For example, we have made an evaluation by running type trait tests from libcxx</div>
<div>with a standard header in OpenCL mode and only a few tests failed due to</div>
<div>the address spaces. None of those required changes in the libcxx code. Instead,</div>
<div>they have revealed bugs in clang (that were fixed in release 11 btw) and issues in</div>
<div>tests due to illegal behavior. These issues are expected for the address space</div>
<div>attributes as there are extra restriction and rules on types attributed by the</div>
<div>address spaces that come from Embedded C. If these restrictions are not desirable</div>
<div>I feel the desirable behavior might be significantly different from the intended use</div>
<div>of address space attributes and therefore it might be better to look at alternative</div>
<div>approaches including adding a dedicated attribute that doesn't propagate into a type</div>
<div>qualifier at all.<br>
</div>
<div><br>
</div>
<div>> casting a names address space pointer to "generic" pointer is valid operation</div>
<div>in all GPGPU programming models I'm aware of (including OpenCL)</div>
<div><br>
</div>
<div>I would like to highlight that generic address space and address space</div>
<div>conversions have only been added in OpenCL 2.0. Furthermore, generic address</div>
<div>space is becoming optional functionality in OpenCL 3.0.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Anastasia<br>
</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> Bader, Alexey <alexey.bader@intel.com><br>
<b>Sent:</b> 30 July 2020 20:51<br>
<b>To:</b> David Rector <davrecthreads@gmail.com>; Anastasia Stulova <Anastasia.Stulova@arm.com><br>
<b>Cc:</b> 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 lang="RU">
<div class="x_WordSection1">
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">David's understanding is right. We would like to be able to call existing C++</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">functions from SYCL applications as much as possible.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">I don't know if analogy with the "const" qualifier is a perfect match here, but</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">casting a names address space pointer to "generic" pointer is valid operation in</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">all GPGPU programming models I'm aware of (including OpenCL). "generic" means</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">that memory can be allocation in any address space, so compiler can't assume any</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">specific address space and must generate code which is valid for any address</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">space. Usually it implies runtime overhead on checking the value of "generic"</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">pointer to handle it properly.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> Alexey et al's alternative to prevent this breakage, if I understand</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> correctly, is to remove the type qualifier, and instead handle all address</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> space semantics in CodeGen (I believe this is what you refer to as keeping the</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> address space "flat").</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">Not exactly. It works as what you described below - "the ideal". We keep address</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">space qualifier if user explicitly applied it, but the difference with OpenCL</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">mode is that "implicit" address space is the same as in regular C++ (i.e.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">default) and we allow conversion to "default" C++ address spaces from explicitly</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">set named address spaces. C++ "default" is treated as "generic" w/o changing C++</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">default address space to OpenCL "generic" address space in Sema type system.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">When SYCL users access memory though SYCL library API memory pointers will be</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">annotated with address space attributes to ensure good performance. Users can</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">obtain a "raw" pointer from SYCL objects to pass it to some generic C++ function</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">and this use case is enabled by the patch https://reviews.llvm.org/D80932.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> It seems to me that approach is not ideal, though, because
</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">>   a) it seems they would lose the type-checking benefits of implementing as a</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">>  type qualifier (e.g. imagine if "const" qualifiers were removed and handled</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">>  instead in CodeGen), and </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">>  b) I think it really is important for the AST to maintain a clear</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">>   representation of all target-independent semantics, including address</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">>   spaces, so that users can easily reason about their code in AST matchers</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">>   etc.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">Address space attributes are preserved in AST if they are applied explicitly on</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">source code, but they are not implicitly applied to all types.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">Type-checking is performed for OpenCL address space attributes (e.g. casts</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">between "named" address spaces are not allowed) and C++ type qualifiers like</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">"const" are respected.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> So the ideal, it seems to me, for everyone’s sake, would be for OpenCL</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> qualifiers to behave more like "const" — there would be a default, a la</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> "non-const", that is applied to all types not explicitly qualified, so that</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> one could enable OpenCL mode and regular code would still work by default.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">I believe it's what we have in our implementation.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> In reality though, I imagine this has all already been thought over</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> thoroughly, and it has been determined it really is unavoidable to break</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> standard C++ semantics in order to support address spaces; that there really</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> is no default that could be inferred for arbitrary types like those used in</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> template arguments.  </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> But perhaps it is worthwhile to think it through one more time, to question</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> whether there may be some way to deduce type qualifiers properly in every</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">> case, because the issue that Alexey et al raise is a good one I think.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">There is LLVM transformation pass which infers address space information at LLVM</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">IR level: https://llvm.org/doxygen/InferAddressSpaces_8cpp_source.html</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">It helps to avoid performance overhead for regular C++ code called from SYCL</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" lang="EN-US">annotated parts.</span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="" 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_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<b><span lang="EN-US">From:</span></b><span lang="EN-US"> David Rector <davrecthreads@gmail.com>
<br>
<b>Sent:</b> Thursday, July 30, 2020 2:33 AM<br>
<b>To:</b> Anastasia Stulova <Anastasia.Stulova@arm.com><br>
<b>Cc:</b> Bader, Alexey <alexey.bader@intel.com>; cfe-dev (cfe-dev@lists.llvm.org) <cfe-dev@lists.llvm.org>; rjmccall@apple.com; nd <nd@arm.com><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Re-use OpenCL address space attributes for SYCL</span></p>
</div>
</div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">If I understand their proposal correctly, from the discussion Alexey linked to in </span><u><span style="color:#813A5F"><a href="https://reviews.llvm.org/D80932#2073542"><span lang="EN-US">https://reviews.llvm.org/D80932#2073542</span></a></span></u><u><span style="color:#453CCC" lang="EN-US">,</span></u><span lang="EN-US"> 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.</span></p>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">That definitely seems like a worthy goal if it could be properly accomplished. </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">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.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">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.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">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.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">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").
  </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">It seems to me that approach is not ideal, though, because </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">  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 </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">  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.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">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.</span></p>
</div>
<div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">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.  </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">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.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"><br>
<br>
</span></p>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US">On Jul 29, 2020, at 5:42 PM, Anastasia Stulova <</span><a href="mailto:Anastasia.Stulova@arm.com"><span lang="EN-US">Anastasia.Stulova@arm.com</span></a><span lang="EN-US">> wrote:</span></p>
</div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
<div>
<div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US">> 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.?</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US">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.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US">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.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US">> 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</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US">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.</span></p>
</div>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:12.0pt" lang="EN-US"> </span></p>
</div>
<div class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;text-align:center" align="center">
<hr style="width:535.1pt" width="713" size="2" align="center">
</div>
<div id="x_divRplyFwdMsg">
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<b><span lang="EN-US">From:</span></b><span class="x_apple-converted-space"><span lang="EN-US"> </span></span><span lang="EN-US">David Rector <</span><a href="mailto:davrecthreads@gmail.com"><span lang="EN-US">davrecthreads@gmail.com</span></a><span lang="EN-US">><br>
<b>Sent:</b><span class="x_apple-converted-space"> </span>27 July 2020 22:32<br>
<b>To:</b><span class="x_apple-converted-space"> </span>Bader, Alexey <</span><a href="mailto:alexey.bader@intel.com"><span lang="EN-US">alexey.bader@intel.com</span></a><span lang="EN-US">><br>
<b>Cc:</b><span class="x_apple-converted-space"> </span>Anastasia Stulova <</span><a href="mailto:Anastasia.Stulova@arm.com"><span lang="EN-US">Anastasia.Stulova@arm.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"> <</span><a href="mailto:rjmccall@apple.com"><span lang="EN-US">rjmccall@apple.com</span></a><span lang="EN-US">>; 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><span class="x_apple-converted-space"> </span>Re: [cfe-dev] [RFC] Re-use OpenCL address space attributes for SYCL</span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US"></span></p>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US"> </span></p>
</div>
</div>
<div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">On Jul 27, 2020, at 12:18 PM, Bader, Alexey via cfe-dev <</span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC"><a href="mailto:cfe-dev@lists.llvm.org"><span lang="EN-US">cfe-dev@lists.llvm.org</span></a></span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">>
 wrote:</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" 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" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> > the same case when variable declaration is not explicitly annotated with address</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> > space attribute. According to language semantics such objects are allocated in</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> > generic address space, but the problem is that most OpenCL implementations have</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> > problems with consuming SPIR-V files with global variables in generic address</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> > space. As an alternative to CodeGen changes we can consider handling this issue</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> > in SPIR-V translator tool.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" 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" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> it with John McCall or someone who is more experienced with CodeGen architecture.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" 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" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> deduced address space to generic straight after? You already add similar casts for</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">> pointers that are annotated with address spaces through the user code, right?</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" 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" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">I don't see how it can be done without breaking C++ semantics demonstrated in</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<u><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#813A5F"><a href="https://reviews.llvm.org/D80932#2073542"><span lang="EN-US">https://reviews.llvm.org/D80932#2073542</span></a></span></u><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#453CCC" lang="EN-US">. </span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif; color:#813A5F" lang="EN-US"></span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">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.?</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">I.e., referring to the examples linked to above: perhaps the problem is *not* that that OpenCL changes `</span><span style="font-size:7.5pt; font-family:"Menlo",serif" lang="EN-US">int
 var</span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">` to `</span><span style="font-size:7.5pt; font-family:"Menlo",serif" lang="EN-US">__private int var</span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">`,
 but rather that it does not *also* change `</span><span style="font-size:7.5pt; font-family:"Menlo",serif" lang="EN-US">int* ptr1 = &var</span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">` to `</span><span style="font-size:7.5pt; font-family:"Menlo",serif" lang="EN-US">__private
 int* __private ptr1 = &var</span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">` (or whatever the proper default qualifiers are) and `</span><span style="font-size:7.5pt; font-family:"Helvetica",sans-serif" lang="EN-US">s</span><span style="font-size:7.5pt; font-family:"Menlo",serif" lang="EN-US">td::is_same<T,
 int></span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">` to `</span><span style="font-size:7.5pt; font-family:"Menlo",serif" lang="EN-US">std::is_same<T, __private int></span><span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">`
 when in OpenCL (or SYCL) mode.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">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.</span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US"> </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span style="font-size:9.0pt; font-family:"Helvetica",sans-serif" lang="EN-US">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.</span></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="x_MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;">
<span lang="EN-US"> </span></p>
</div>
</div>
</div>
</div>
</body>
</html>