This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compilers and RCU readers: Once more unto the breach!
- From: "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- To: Linus Torvalds <torvalds at linux-foundation dot org>
- Cc: Linux Kernel Mailing List <linux-kernel at vger dot kernel dot org>, c++std-parallel at accu dot org, "linux-arch at vger dot kernel dot org" <linux-arch at vger dot kernel dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, p796231 <Peter dot Sewell at cl dot cam dot ac dot uk>, "mark dot batty at cl dot cam dot ac dot uk" <Mark dot Batty at cl dot cam dot ac dot uk>, Peter Zijlstra <peterz at infradead dot org>, Will Deacon <will dot deacon at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, David Howells <dhowells at redhat dot com>, Andrew Morton <akpm at linux-foundation dot org>, Ingo Molnar <mingo at kernel dot org>, michaelw at ca dot ibm dot com
- Date: Tue, 19 May 2015 19:41:48 -0700
- Subject: Re: Compilers and RCU readers: Once more unto the breach!
- Authentication-results: sourceware.org; auth=none
- References: <20150520005510 dot GA23559 at linux dot vnet dot ibm dot com> <CA+55aFy_8V-rbE9FQMHx6tXjj8HHKZuKSJvnRPVYvpk46EQA1g at mail dot gmail dot com> <CA+55aFxOtcB8AYCpLQBGSXK=8_Vh4uDs5HEpzGpPy+hgz542ag at mail dot gmail dot com>
- Reply-to: paulmck at linux dot vnet dot ibm dot 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