<html 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)">
<style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:226041717;
mso-list-type:hybrid;
mso-list-template-ids:-1613047408 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">The best reason I can see to layer libcxx atomics on the C11 atomics is that there’s probably no other way to ensure interoperability between C1* and C++1* for toolchains that want to do that. I agree with your assessment that a toolchain
using embeddeds lock for C1* _Atomic(T) will just work with libcxx – I haven’t any doubt.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There are at least two issues RE: _Atomic(T) where my situation is concerned:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">We’re not interested in implementing C1* at the moment, and it’s not actually a requirement to implement C++1* either. Hence we’re more interested in the __atomic_* backend than the
__c11_atomic_* backend to libcxx atomic.<o:p></o:p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1">This is a great reason for libcxx to retain this backend: implementations of C++ that don’t depend on C.<o:p></o:p></li></ol>
</li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">We don’t control what host CPU compilers will do for _Atomic(T) and even if we did, we’re locked into platform ABI choices for host CPUs that have largely shied from embedded locks
(except on Windows) and we’d still have to match.<o:p></o:p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1">Given our C++ centric focus, it’s much simpler to address this in the library layer.<o:p></o:p></li></ol>
</li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This being said, my proposed change makes it possible to turn this path on or off regardless of whether the __c11_atomic_* or the __atomic_* backend is used. At the moment I’m poposing to turn it on merely because LIBCXX_FREESTANDING is
set, but we could be more selective than that, it could be part of what __config selects when in a Freestanding configuration. We do need to be careful that there exist at least one public configuration that uses it; I don’t want to put this path in there
and only turn it on in a private configuration.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Olivier<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Ben Craig <ben.craig@ni.com><br>
<b>Date: </b>Monday, December 31, 2018 at 6:16 PM<br>
<b>To: </b>Olivier Giroux <OGiroux@nvidia.com>, "libcxx-dev@lists.llvm.org" <libcxx-dev@lists.llvm.org><br>
<b>Subject: </b>Re: [libcxx-dev] proposal: decoupling Freestanding atomic<T> from libatomic.a<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div id="divtagdefaultwrapper">
<p><span style="font-size:12.0pt;color:black">I think the most robust solution is for your compiler to implement C11 _Atomic, and for that type to be sufficiently large to hold your value and your spin lock. I think that most of the libcxx implementation will
"just work" at that point, although there are possibly some hidden bugs where something mistakenly assumes that sizeof(T) = = sizeof(_Atomic(T)).<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">Making the compiler generate _Atomic correctly also gives you a lot of C compatibility.<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">If C11 compatibility isn't a big concern, and / or getting that feature into the compilers that you need isn't an option, then your approach sounds fine to me. I don't make the decisions around here though :)<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">For the binary compatibility concerns... I don't have great answers. On the one hand, I want to believe that the choice of freestanding or hosted is a platform decision, and that you shouldn't ever mix freestanding
object files with hosted object files. On the other hand, an awful lot of people that aren't doing embedded, drivers, or GPU programming seem interested in freestanding, and I'm afraid that they may very well want to build one chunk of code with a freestanding
flag as a style checker / optimizer, and another part of their code with hosted. I'm not sure if it make sense to try and support that second group.<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">Another binary compatibility note... my search skills are failing me, but I recall seeing some blog post or documentation that basically states that, when in doubt, you should generate a library call. You can migrate
from a library call to inline code over time, but you can't migrate the other direction without breaking compatibility. I don't think that affects the specific design questions you had though.<o:p></o:p></span></p>
</div>
</div>
<DIV>
<HR>
</DIV>
<DIV>This email message is for the sole use of the intended recipient(s) and may
contain confidential information. Any unauthorized review, use, disclosure
or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message. </DIV>
<DIV>
<HR>
</DIV>
</body>
</html>