<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Menlo;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="RU" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">David's understanding is right. We would like to be able to call existing C++<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">functions from SYCL applications as much as possible.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I don't know if analogy with the "const" qualifier is a perfect match here, but<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">casting a names address space pointer to "generic" pointer is valid operation in<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">all GPGPU programming models I'm aware of (including OpenCL). "generic" means<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">that memory can be allocation in any address space, so compiler can't assume any<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">specific address space and must generate code which is valid for any address<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">space. Usually it implies runtime overhead on checking the value of "generic"<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">pointer to handle it properly.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> Alexey et al's alternative to prevent this breakage, if I understand<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> correctly, is to remove the type qualifier, and instead handle all address<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> space semantics in CodeGen (I believe this is what you refer to as keeping the<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> address space "flat").<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Not exactly. It works as what you described below - "the ideal". We keep address<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">space qualifier if user explicitly applied it, but the difference with OpenCL<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">mode is that "implicit" address space is the same as in regular C++ (i.e.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">default) and we allow conversion to "default" C++ address spaces from explicitly<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">set named address spaces. C++ "default" is treated as "generic" w/o changing C++<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">default address space to OpenCL "generic" address space in Sema type system.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">When SYCL users access memory though SYCL library API memory pointers will be<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">annotated with address space attributes to ensure good performance. Users can<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">obtain a "raw" pointer from SYCL objects to pass it to some generic C++ function<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">and this use case is enabled by the patch https://reviews.llvm.org/D80932.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> It seems to me that approach is not ideal, though, because
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> a) it seems they would lose the type-checking benefits of implementing as a<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> type qualifier (e.g. imagine if "const" qualifiers were removed and handled<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> instead in CodeGen), and
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> b) I think it really is important for the AST to maintain a clear<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> representation of all target-independent semantics, including address<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> spaces, so that users can easily reason about their code in AST matchers<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> etc.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Address space attributes are preserved in AST if they are applied explicitly on<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">source code, but they are not implicitly applied to all types.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Type-checking is performed for OpenCL address space attributes (e.g. casts<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">between "named" address spaces are not allowed) and C++ type qualifiers like<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">"const" are respected.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> So the ideal, it seems to me, for everyone’s sake, would be for OpenCL<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> qualifiers to behave more like "const" — there would be a default, a la<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> "non-const", that is applied to all types not explicitly qualified, so that<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> one could enable OpenCL mode and regular code would still work by default.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I believe it's what we have in our implementation.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> In reality though, I imagine this has all already been thought over<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> thoroughly, and it has been determined it really is unavoidable to break<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> standard C++ semantics in order to support address spaces; that there really<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> is no default that could be inferred for arbitrary types like those used in<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> template arguments.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> But perhaps it is worthwhile to think it through one more time, to question<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> whether there may be some way to deduce type qualifiers properly in every<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">> case, because the issue that Alexey et al raise is a good one I think.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">There is LLVM transformation pass which infers address space information at LLVM<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">IR level: https://llvm.org/doxygen/InferAddressSpaces_8cpp_source.html<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">It helps to avoid performance overhead for regular C++ code called from SYCL<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">annotated parts.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></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="MsoNormal"><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<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><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 lang="EN-US" style="color:#453CCC">,</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.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">That definitely seems like a worthy goal if it could be properly accomplished. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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"). <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">It seems to me that approach is not ideal, though, because <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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 <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><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:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt">> 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.?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt">> 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<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt">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.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="713" style="width:535.1pt" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span class="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="apple-converted-space"> </span>27 July 2020 22:32<br>
<b>To:</b><span class="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="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="apple-converted-space"> </span>Re: [cfe-dev] [RFC] Re-use OpenCL address space attributes for SYCL</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">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 lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">>
wrote:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> > I don't think (2) deal with language semantics. I assume we both talking about<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> > the same case when variable declaration is not explicitly annotated with address<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> > space attribute. According to language semantics such objects are allocated in<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> > generic address space, but the problem is that most OpenCL implementations have<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> > problems with consuming SPIR-V files with global variables in generic address<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> > space. As an alternative to CodeGen changes we can consider handling this issue<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> > in SPIR-V translator tool.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> I am not really a CodeGen expert, maybe it will be ok. I think it's better if you discuss<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> it with John McCall or someone who is more experienced with CodeGen architecture.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> Why don't you just do regular address space deduction in Sema and then cast the<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> deduced address space to generic straight after? You already add similar casts for<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> pointers that are annotated with address spaces through the user code, right?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">> This approach will probably allow to reuse the logic from OpenCL and simplify CodeGen.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">I don't see how it can be done without breaking C++ semantics demonstrated in<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><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 lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#453CCC">. </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#813A5F"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">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.?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">I.e., referring to the examples linked to above: perhaps the problem is *not* that that OpenCL changes `</span><span lang="EN-US" style="font-size:7.5pt;font-family:"Menlo",serif">int
var</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">` to `</span><span lang="EN-US" style="font-size:7.5pt;font-family:"Menlo",serif">__private int var</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">`,
but rather that it does not *also* change `</span><span lang="EN-US" style="font-size:7.5pt;font-family:"Menlo",serif">int* ptr1 = &var</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">` to `</span><span lang="EN-US" style="font-size:7.5pt;font-family:"Menlo",serif">__private
int* __private ptr1 = &var</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">` (or whatever the proper default qualifiers are) and `</span><span lang="EN-US" style="font-size:7.5pt;font-family:"Helvetica",sans-serif">s</span><span lang="EN-US" style="font-size:7.5pt;font-family:"Menlo",serif">td::is_same<T,
int></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">` to `</span><span lang="EN-US" style="font-size:7.5pt;font-family:"Menlo",serif">std::is_same<T, __private int></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">`
when in OpenCL (or SYCL) mode.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica",sans-serif">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.<o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>