From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Michael Matz <matz@suse.de>
Cc: parallel@lists.isocpp.org, linux-arch@vger.kernel.org,
gcc@gcc.gnu.org, p796231 <Peter.Sewell@cl.cam.ac.uk>,
llvm-dev@lists.llvm.org, will.deacon@arm.com,
linux-kernel@vger.kernel.org, dhowells@redhat.com,
peterz@infradead.org, Ramana.Radhakrishnan@arm.com,
Luc Maranget <luc.maranget@inria.fr>,
akpm@linux-foundation.org, Jade Alglave <j.alglave@ucl.ac.uk>,
torvalds@linux-foundation.org, mingo@kernel.org
Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition
Date: Mon, 29 Feb 2016 17:28:20 -0800 [thread overview]
Message-ID: <20160301012820.GJ3577@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LSU.2.20.1602291837100.20277@wotan.suse.de>
On Mon, Feb 29, 2016 at 07:17:55PM +0100, Michael Matz wrote:
> Hi,
>
> On Sat, 27 Feb 2016, Paul E. McKenney wrote:
>
> > But we do already have something very similar with signed integer
> > overflow. If the compiler can see a way to generate faster code that
> > does not handle the overflow case, then the semantics suddenly change
> > from twos-complement arithmetic to something very strange. The standard
> > does not specify all the ways that the implementation might deduce that
> > faster code can be generated by ignoring the overflow case, it instead
> > simply says that signed integer overflow invoked undefined behavior.
> >
> > And if that is a problem, you use unsigned integers instead of signed
> > integers.
> >
> > So it seems that we should be able to do something very similar here.
>
> For this case the important pice of information to convey one or the other
> meaning in source code is the _type_ of involved entities, not annotations
> on the operations. signed type -> undefined overflow, unsigned type ->
> modulo arithmetic; easy, and it nicely carries automatically through
> operation chains (and pointers) without any annotations.
>
> I feel much of the complexity in the memory order specifications, also
> with your recent (much better) wording to explain dependency chains, would
> be much easier if the 'carries-dependency' would be encoded into the types
> of operands. For purpose of example, let's call the marker "blaeh" (not
> atomic to not confuse with existing use :) ):
>
> int foo;
> blaeh int global;
> int *somep;
> blae int *blaehp;
> f () {
> blaehp = &foo; // might be okay, adds restrictions on accesses through
> // blaehp, but not through 'foo' directly
> blaehp = &global;
> if (somep == blaehp)
> {
> /* Even though the value is equal ... */
> ... *blaehp ... /* ... a compiler can't rewrite this into *somep */
> }
> }
>
> A "carries-dependency" on some operation (e.g. a call) would be added by
> using a properly typed pointer at those arguments (or return type) where
> it matters. You can't give a blaeh pointer to something only accepting
> non-blaeh pointers (without cast).
>
> Pointer addition and similar transformations involving a blaeh pointer and
> some integer would still give a blaeh pointer, and hence by default also
> solve the problem of cancellations.
>
> Such marking via types would not solve all problems in an optimal way if
> you had two overlapping but independend dependency chains (all of them
> would collapse to one chain and hence made dependend, which still is
> conservatively correct).
>
> OTOH introducing new type qualifiers is a much larger undertaking, so I
> can understand one wants to avoid this. I think it'd ultimately be
> clearer, though.
As has been stated in this thread, we do need the unmarked variant.
For the marked variant, there are quite a few possible solutions with
varying advantages and disadvantages:
o Attribute already exists, but is not carried by the type system.
Could be enforced by external tools.
o Storage class could be added with fewer effects on the type
system, but the reaction to this suggestion in October was
not all that positive.
o Non-type keywords for objects has been suggested, might be worth
revisiting.
o Adding to the type system allows type enforcement on the one
hand, but makes it harder to write code that can be used for
both RCU-protected and not-RCU-protected data structures.
(This sort of thing is not uncommon in the Linux kernel.)
There are probably others, but those are the ones I recall at the
moment.
Thanx, Paul
prev parent reply other threads:[~2016-03-01 1:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 1:10 Proposal for new memory_order_consume definition Paul E. McKenney
2016-02-20 2:15 ` [isocpp-parallel] " Tony V E
2016-02-20 19:53 ` Paul E. McKenney
[not found] ` <CAPUmR1bw=N4NkjAK1zn_X0+84KEaEAM6HZCHZJy_txqC9hMgSg@mail.gmail.com>
2016-02-26 23:56 ` Lawrence Crowl
2016-02-27 17:06 ` Paul E. McKenney
[not found] ` <CA+55aFyHmykKc=YybJMo9ZUO352MY5noJVB4-K1Lkjmw4UHXfA@mail.gmail.com>
2016-02-27 23:10 ` Paul E. McKenney
2016-02-28 8:27 ` Markus Trippelsdorf
2016-02-28 16:13 ` Linus Torvalds
2016-02-28 16:50 ` [llvm-dev] " cbergstrom
2016-02-29 17:37 ` Michael Matz
2016-02-29 17:57 ` Linus Torvalds
2016-02-29 19:38 ` Lawrence Crowl
2016-02-29 21:12 ` [llvm-dev] " James Y Knight
2016-02-29 20:45 ` Toon Moene
2016-02-29 18:17 ` Michael Matz
2016-03-01 1:28 ` Paul E. McKenney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160301012820.GJ3577@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Peter.Sewell@cl.cam.ac.uk \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm-dev@lists.llvm.org \
--cc=luc.maranget@inria.fr \
--cc=matz@suse.de \
--cc=mingo@kernel.org \
--cc=parallel@lists.isocpp.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).