220 27773 <51b50bc6-941e-4c52-b124-6a0e98838a45@isocpp.org> article
Path: news.gmane.org!.POSTED!not-for-mail
From: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: For atomic<T> instances, is there a need for a memory
 order allowing a load to be optimized out?
Date: Sat, 13 Aug 2016 16:55:24 -0700 (PDT)
Lines: 62
Approved: news@gmane.org
Message-ID: <51b50bc6-941e-4c52-b124-6a0e98838a45@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1479_617374303.1471132524556"
X-Trace: blaine.gmane.org 1471132533 7045 195.159.176.226 (13 Aug 2016 23:55:33 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Sat, 13 Aug 2016 23:55:33 +0000 (UTC)
To: ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Original-X-From: std-proposals+bncBDFLZXWOVYIBB3XGX26QKGQEMVAXGCY@isocpp.org Sun Aug 14 01:55:29 2016
Return-path: <std-proposals+bncBDFLZXWOVYIBB3XGX26QKGQEMVAXGCY@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-qk0-f197.google.com ([209.85.220.197])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <std-proposals+bncBDFLZXWOVYIBB3XGX26QKGQEMVAXGCY@isocpp.org>)
	id 1bYim0-0001Yf-Mz
	for gclcip-std-proposals@m.gmane.org; Sun, 14 Aug 2016 01:55:28 +0200
Original-Received: by mail-qk0-f197.google.com with SMTP id i140sf48997893qke.0
        for <gclcip-std-proposals@m.gmane.org>; Sat, 13 Aug 2016 16:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=isocpp-org.20150623.gappssmtp.com; s=20150623;
        h=date:from:to:message-id:subject:mime-version:x-original-sender
         :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group
         :list-post:list-help:list-archive:list-subscribe:list-unsubscribe;
        bh=/xVWzBobBO0zQnh4xfMy2YwKVHmzkWLN7R7TCdMfap8=;
        b=mJUezVuTO6E5Mjgsph9ca6nLU81DHUnFYwwLq4cAVgWySRgOb3bA0xYmPj5++oe3gq
         iLidjWzjgnAhUAWUexqBW/zDOvxsq+13e+eiSlfyZR2PGFkkje27rVfTkH6MCsQzqMy0
         yONjnXCtvekCUWT4Mhiay3zNbzu1NVcWaOfYNabuveHOuwGaPTrgMeq7beGAEoDkux8w
         V9V6aThTozARA6WE3XExfcX+BgwNLvqWTwWL1W8aDwjXfO70mzn06bPcznhcFSxmi4gG
         KXKkOE95pCJUJSzrSQSMCMQUYyss8TZPbeIjSGd987Dwt0vz1IStoCUO5m63Rgup9qOs
         n9/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:date:from:to:message-id:subject:mime-version
         :x-original-sender:reply-to:precedence:mailing-list:list-id
         :x-spam-checked-in-group:list-post:list-help:list-archive
         :list-subscribe:list-unsubscribe;
        bh=/xVWzBobBO0zQnh4xfMy2YwKVHmzkWLN7R7TCdMfap8=;
        b=SrZEdkkLOhibXnzbCQvK5mjauJM/E596uBBYuuU0AGBy7t+QFAH4v/VGNJdKr6foVb
         sF3DIOnD1d3+xITf3spWXyidNYnb0B7DotNEnxRTSnbMB/4oG/re7clwygjmBNmlR/OI
         7fKmOuHcO5CTzuXlEIl725KJQ7qKM8Wt8nHZ529MHEmXBV5kUK4BQcs7m22pLncdkR3O
         mjSsGbgotjieqAHgErTUX5L+40iriLr0LKwjXnAIYXKNw8wTe1vBHbkXLjmhdPCcxGwT
         kSypNUEY1tQ/xw8vSP5XWXLv9+4URtg+MwsRHbAz1n0IeGpsQTeP8NJw6vEvmsipgkQ5
         kxEA==
X-Gm-Message-State: AEkoous/ck4Vn7SJppBti1zAtltG5WbcSnTP6l1X+i6aUkg9QdMzYLS4FFUsFw0o5imAsQ==
X-Received: by 10.129.50.84 with SMTP id y81mr15864162ywy.33.1471132528675;
        Sat, 13 Aug 2016 16:55:28 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.107.46.156 with SMTP id u28ls2208547iou.14.gmail; Sat, 13 Aug
 2016 16:55:25 -0700 (PDT)
X-Received: by 10.36.107.7 with SMTP id v7mr219008itc.10.1471132525865;
        Sat, 13 Aug 2016 16:55:25 -0700 (PDT)
X-Original-Sender: wkaras@yahoo.com
X-Original-From: Walt Karas <wkaras@yahoo.com>
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <https://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <https://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <https://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <https://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <https://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:27773
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/27773>

------=_Part_1479_617374303.1471132524556
Content-Type: multipart/alternative; 
	boundary="----=_Part_1480_725365478.1471132524556"

------=_Part_1480_725365478.1471132524556
Content-Type: text/plain; charset=UTF-8

For the code:

atomic<int> i;
int sum = i.load(memory_order_relaxed);
sum += i.load(memory_order_relaxed);

both clang and gcc will load i from memory twice.  Was this the intent of 
the Standard?

If an atomic instance is only ever written in a single thread, then loads 
in that thread can correctly be optimized out I think.  Do we need another 
memory order (memory_order_none perhaps) to indicate loads of the instance 
from memory are not necessary if the value of it is still in register(s) 
(due to a preceding load or store)?

-- 
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org.

------=_Part_1480_725365478.1471132524556
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">For the code:<div><br></div><div>atomic&lt;int&gt; i;</div=
><div>int sum =3D i.load(memory_order_relaxed);</div><div>sum +=3D i.load(m=
emory_order_relaxed);</div><div><br></div><div>both clang and gcc will load=
 i from memory twice. =C2=A0Was this the intent of the Standard?</div><div>=
<br></div><div>If an atomic instance is only ever written in a single threa=
d, then loads in that thread can correctly be optimized out I think. =C2=A0=
Do we need another memory order (memory_order_none perhaps) to indicate loa=
ds of the instance from memory are not necessary if the value of it is stil=
l in register(s) (due to a preceding load or store)?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45=
%40isocpp.org</a>.<br />

------=_Part_1480_725365478.1471132524556--

------=_Part_1479_617374303.1471132524556--

.
