This is the mail archive of the
mailing list for the GCC project.
Re: Compilers and RCU readers: Once more unto the breach!
- From: Will Deacon <will dot deacon at arm dot com>
- To: "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- Cc: Linus Torvalds <torvalds at linux-foundation dot org>, Linux Kernel Mailing List <linux-kernel at vger dot kernel dot org>, "c++std-parallel at accu 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>, 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" <michaelw at ca dot ibm dot com>
- Date: Wed, 20 May 2015 16:46:17 +0100
- 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> <20150520024148 dot GD6776 at linux dot vnet dot ibm dot com> <20150520114745 dot GC11498 at arm dot com> <20150520121522 dot GH6776 at linux dot vnet dot ibm dot com>
On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> On Wed, May 20, 2015 at 12:47:45PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote:
> > > 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?
> > Whilst I understand what you're saying (the ARM architecture makes these
> > sorts of distinctions when calling out dependency-based ordering), it
> > feels like we're dangerously close to defining the difference between a
> > true and a false dependency. If we want to do this in the context of the
> > C language specification, you run into issues because you need to evaluate
> > the program in order to determine data values in order to determine the
> > nature of the dependency.
> Indeed, something like this does -not- carry a dependency from the
> memory_order_consume load to q:
> char *p, q;
> p = atomic_load_explicit(&gp, memory_order_consume);
> q = gq + (intptr_t)p - (intptr_t)p;
> If this was compiled with -O0, ARM and Power might well carry a
> dependency, but given any optimization, the assembly language would have
> no hint of any such dependency. So I am not seeing any particular danger.
The above is a welcome relaxation over C11, since ARM doesn't even give
you ordering based off false data dependencies. My concern is more to do
with how this can be specified precisely without prohibing honest compiler
and hardware optimisations.
Out of interest, how do you tackle examples (4) and (5) of (assuming the
reads are promoted to consume loads)?:
my understanding is that you permit both outcomes (I appreciate you're
not directly tackling out-of-thin-air, but treatment of dependencies
is heavily related).
> > You tackle this above by saying "to allow the compiler to precisely
> > determine the resulting value", but I can't see how that can be cleanly
> > fitted into something like the C language specification.
> I am sure that there will be significant rework from where this document
> is to language appropriate from the standard. Which is why I am glad
> that Jens is taking an interest in this, as he is particularly good at
> producing standards language.
Ok. I'm curious to see how that comes along.
> > Even if it can,
> > then we'd need to reword the "?:" treatment that you currently have:
> > "If a pointer is part of a dependency chain, and that pointer appears
> > in the entry of a ?: expression selected by the condition, then the
> > chain extends to the result."
> > which I think requires the state of the condition to be known statically
> > if we only want to extend the chain from the selected expression. In the
> > general case, wouldn't a compiler have to assume that the chain is
> > extended from both?
> In practice, yes, if the compiler cannot determine which expression is
> selected, it must arrange for the dependency to be carried from either,
> depending on the run-time value of the condition. But you would have
> to work pretty hard to create code that did not carry the dependencies
> as require, not?
I'm not sure... you'd require the compiler to perform static analysis of
loops to determine the state of the machine when they exit (if they exit!)
in order to show whether or not a dependency is carried to subsequent
operations. If it can't prove otherwise, it would have to assume that a
dependency *is* carried, and it's not clear to me how it would use this
information to restrict any subsequent dependency removing optimisations.
I guess that's one for the GCC folks.
> > Additionally, what about the following code?
> > char *x = y ? z : z;
> > Does that extend a dependency chain from z to x? If so, I can imagine a
> > CPU breaking that in practice.
> I am not seeing this. I would expect the compiler to optimize to
> something like this:
> char *x = z;
> How does this avoid carrying the dependency? Or are you saying that
> ARM loses the dependency via a store to memory and a later reload?
> That would be a bit surprising...
I was thinking that the compiler would have to preserve the conditional
structure so that the dependency chain could be tracked correctly, but
if it can just assume that the dependency is carried regardless of y then
I agree that it doesn't matter for this code. All the CPU could do is
remove the conditional hazard.
> > > > 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.
> > For the avoidance of doubt, I'm completely behind any attempts to tackle
> > this problem, but I anticipate an uphill struggle getting this text into
> > the C standard. Is your intention to change the carries-a-dependency
> > relation to encompass this change?
> I completely agree that this won't be easy, but this is the task at hand.
> And yes, the intent is to change carries-a-dependency, given that the
> current wording isn't helping anything. ;-)
Agreed on that!