From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
c++std-parallel@accu.org,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
p796231 <Peter.Sewell@cl.cam.ac.uk>,
"mark.batty@cl.cam.ac.uk" <Mark.Batty@cl.cam.ac.uk>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
David Howells <dhowells@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
michaelw@ca.ibm.com
Subject: Re: Compilers and RCU readers: Once more unto the breach!
Date: Tue, 19 May 2015 19:34:03 -0700 [thread overview]
Message-ID: <20150520023402.GC6776@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+55aFy_8V-rbE9FQMHx6tXjj8HHKZuKSJvnRPVYvpk46EQA1g@mail.gmail.com>
On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote:
> On Tue, May 19, 2015 at 5:55 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> >
> > http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf
>
> >From a very quick read-through, the restricted dependency chain in 7.9
> seems to be reasonable, and essentially covers "thats' what hardware
> gives us anyway", making compiler writers happy.
>
> I would clarify the language somewhat:
>
> - it says that the result of a cast of a pointer is a dependency. You
> need to make an exception for casting to bool, methinks (because
> that's effectively just a test-against-NULL, which you later describe
> as terminating the dependency).
>
> Maybe get rid of the "any type", and just limit it to casts to
> types of size intptr_t, ie ones that don't drop significant bits. All
> the other rules talk about [u]intptr_t anyway.
Excellent point! I now say:
If a pointer is part of a dependency chain, then casting it
(either explicitly or implicitly) to any pointer-sized type
extends the chain to the result.
If this approach works out, the people in the Core Working Group will
come up with alternative language-lawyer-proof wording, but this informal
version will hopefully do for the moment.
> - you clarify that the trivial "& 0" and "| ~0" kill the dependency
> chain, but if you really want to be a stickler, you might want to
> extend it to a few more cases. Things like "& 1" (to extract a tag
> from the lot bit of a tagged pointer) should likely also drop the
> dependency, since a compiler would commonly end up using the end
> result as a conditional even if the code was written to then use
> casting etc to look like a dereference.
Ah, how about the following?
If a value of type intptr_t or uintptr_t is part of a dependency
chain, and if that value is one of the operands to an & or |
infix operator whose result has too few or too many bits set,
then the resulting value will not be part of any dependency
chain. For example, on a 64-bit system, if p is part of a
dependency chain, then (p & 0x7) provides just the tag bits,
and normally cannot even be legally dereferenced. Similarly,
(p | ~0) normally cannot be legally dereferenced.
> - the "you can add/subtract integral values" still opens you up to
> language lawyers claiming "(char *)ptr - (intptr_t)ptr" preserving the
> dependency, which it clearly doesn't. But language-lawyering it does,
> since all those operations (cast to pointer, cast to integer,
> subtracting an integer) claim to be dependency-preserving operations.
My thought was that the result of "(char *)ptr - (intptr_t)ptr" is a
NULL pointer in most environments, and dereferencing a NULL pointer
is undefined behavior. So it becomes irrelevant whether or not the
NULL pointer carries a dependency.
There are some stranger examples, such as "(char *)ptr - ((intptr_t)ptr)/7",
but in that case, if the resulting pointer happens by chance to reference
valid memory, I believe a dependency would still be carried. Of course,
if you are producing code like that, I am guessing that dependencies are
the very least of your concerns.
However, I will give this some more thought.
> So I think you want to limit the logical operators to things that
> don't mask off too many bits, and you should probably limit the
> add/subtract operations some way (maybe specify that the integer value
> you add/subtract cannot be related to the pointer). But I think
> limiting it to mostly pointer ops (and a _few_ integer operations to
> do offsets and remove tag bits) is otherwise a good approach.
Glad you mostly like it! ;-)
Thanx, Paul
next prev parent reply other threads:[~2015-05-20 2:34 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 0:55 Compilers and RCU readers: Once more unto the breach! Paul E. McKenney
2015-05-20 1:57 ` Linus Torvalds
2015-05-20 2:10 ` Linus Torvalds
2015-05-20 2:41 ` Paul E. McKenney
2015-05-20 11:47 ` Will Deacon
2015-05-20 12:15 ` Paul E. McKenney
2015-05-20 15:46 ` Will Deacon
2015-05-20 15:54 ` Andrew Haley
2015-05-20 18:16 ` [c++std-parallel-1632] " Paul E. McKenney
2015-05-21 14:22 ` Michael Matz
2015-05-21 15:10 ` Paul E. McKenney
2015-05-21 16:17 ` Michael Matz
2015-05-21 18:37 ` Paul E. McKenney
2015-05-20 18:16 ` Paul E. McKenney
2015-05-21 19:24 ` Will Deacon
2015-05-21 20:02 ` Paul E. McKenney
2015-05-21 20:42 ` Linus Torvalds
2015-05-21 22:02 ` Paul E. McKenney
2015-05-22 6:43 ` Ingo Molnar
2015-05-22 10:43 ` Richard Kenner
2015-05-22 13:11 ` Paul E. McKenney
2015-05-22 13:12 ` Paul E. McKenney
2015-05-26 17:37 ` [c++std-parallel-1641] " Torvald Riegel
2015-05-22 17:30 ` Will Deacon
2015-05-22 18:55 ` Paul E. McKenney
2015-05-20 13:18 ` David Howells
2015-05-20 13:30 ` Paul E. McKenney
2015-05-20 13:37 ` David Howells
2015-05-20 13:44 ` Ramana Radhakrishnan
2015-05-20 14:03 ` Paul E. McKenney
2015-05-20 14:15 ` Ramana Radhakrishnan
2015-05-20 15:12 ` Paul E. McKenney
2015-05-20 15:46 ` David Howells
2015-05-20 14:02 ` [c++std-parallel-1624] " Paul E. McKenney
2015-05-20 2:34 ` Paul E. McKenney [this message]
2015-05-20 7:34 ` [c++std-parallel-1614] " Jens Maurer
2015-05-20 9:03 ` Richard Biener
2015-05-20 12:02 ` Paul E. McKenney
2015-05-20 12:01 ` [c++std-parallel-1616] " Paul E. McKenney
2015-05-26 17:08 ` [c++std-parallel-1611] " Torvald Riegel
2015-05-27 1:41 ` [c++std-parallel-1651] " Paul E. McKenney
2015-07-14 0:44 ` Paul E. McKenney
2015-09-22 17:00 ` Paul E. McKenney
[not found] ` <CAPUmR1aqV_cQWjE8qC9x2sfmW-1ocKKMtCgNbjZH0cJ-AO2WTg@mail.gmail.com>
2015-09-23 23:26 ` [c++std-parallel-2008] " Paul E. McKenney
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=20150520023402.GC6776@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Mark.Batty@cl.cam.ac.uk \
--cc=Peter.Sewell@cl.cam.ac.uk \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=akpm@linux-foundation.org \
--cc=c++std-parallel@accu.org \
--cc=dhowells@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michaelw@ca.ibm.com \
--cc=mingo@kernel.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).