linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:41:48 -0700	[thread overview]
Message-ID: <20150520024148.GD6776@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+55aFxOtcB8AYCpLQBGSXK=8_Vh4uDs5HEpzGpPy+hgz542ag@mail.gmail.com>

On Tue, May 19, 2015 at 07:10:12PM -0700, Linus Torvalds wrote:
> On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> >  - 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.
> >
> > 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).
> 
> Actually, "not related" doesn't work. For some buddy allocator thing,
> you very much might want some of the bits to be related.

Good point, you could do the buddy-allocator computations with add
and subtract instead of exclusive OR.

> So I think you're better off just saying that operations designed to
> drop significant bits break the dependency chain, and give things like
> "& 1" and "(char *)ptr-(uintptr_t)ptr" as examples of such.
> 
> Making that just an extension of your existing "& 0" language would
> seem to be natural.

Works for me!  I added the following bullet to the list of things
that break dependencies:

	If a pointer is part of a dependency chain, and if the values
	added to or subtracted from that pointer cancel the pointer
	value so as to allow the compiler to precisely determine the
	resulting value, then the resulting value will not be part of
	any dependency chain.  For example, if p is part of a dependency
	chain, then ((char *)p-(uintptr_t)p)+65536 will not be.

Seem reasonable?

> Humans will understand, and compiler writers won't care. They will
> either depend on hardware semantics anyway (and argue that your
> language is tight enough that they don't need to do anything special)
> or they will turn the consume into an acquire (on platforms that have
> too weak hardware).

Agreed.  Plus Core Working Group will hammer out the exact wording,
should this approach meet their approval.

							Thanx, Paul


  reply	other threads:[~2015-05-20  2:41 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 [this message]
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
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=20150520024148.GD6776@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).