This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PATCH 0/5] arch: atomic rework
- From: "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- To: Peter Zijlstra <peterz at infradead dot org>
- Cc: Torvald Riegel <triegel at redhat dot com>, Linus Torvalds <torvalds at linux-foundation 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>, "linux-arch at vger dot kernel dot org" <linux-arch at vger dot kernel dot org>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, "akpm at linux-foundation dot org" <akpm at linux-foundation dot org>, "mingo at kernel dot org" <mingo at kernel dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 12 Feb 2014 09:42:09 -0800
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <20140207042051 dot GL4250 at linux dot vnet dot ibm dot com> <20140207074405 dot GM5002 at laptop dot programming dot kicks-ass dot net> <20140207165028 dot GO4250 at linux dot vnet dot ibm dot com> <20140207165548 dot GR5976 at mudshark dot cambridge dot arm dot com> <20140207180216 dot GP4250 at linux dot vnet dot ibm dot com> <1391992071 dot 18779 dot 99 dot camel at triegel dot csb> <CA+55aFwTwCPMpYTL_vCgNNP0hE8s2sgB0iw-79=xoj99V0JUNA at mail dot gmail dot com> <20140211155941 dot GU4250 at linux dot vnet dot ibm dot com> <1392185194 dot 18779 dot 2239 dot camel at triegel dot csb> <20140212091907 dot GA3545 at laptop dot programming dot kicks-ass dot net>
- Reply-to: paulmck at linux dot vnet dot ibm dot com
On Wed, Feb 12, 2014 at 10:19:07AM +0100, Peter Zijlstra wrote:
> > I don't know the specifics of your example, but from how I understand
> > it, I don't see a problem if the compiler can prove that the store will
> > always happen.
> >
> > To be more specific, if the compiler can prove that the store will
> > happen anyway, and the region of code can be assumed to always run
> > atomically (e.g., there's no loop or such in there), then it is known
> > that we have one atomic region of code that will always perform the
> > store, so we might as well do the stuff in the region in some order.
> >
> > Now, if any of the memory accesses are atomic, then the whole region of
> > code containing those accesses is often not atomic because other threads
> > might observe intermediate results in a data-race-free way.
> >
> > (I know that this isn't a very precise formulation, but I hope it brings
> > my line of reasoning across.)
>
> So given something like:
>
> if (x)
> y = 3;
>
> assuming both x and y are atomic (so don't gimme crap for now knowing
> the C11 atomic incantations); and you can prove x is always true; you
> don't see a problem with not emitting the conditional?
You need volatile semantics to force the compiler to ignore any proofs
it might otherwise attempt to construct. Hence all the ACCESS_ONCE()
calls in my email to Torvald. (Hopefully I translated your example
reasonably.)
Thanx, Paul
> Avoiding the conditional changes the result; see that control dependency
> email from earlier. In the above example the load of X and the store to
> Y are strictly ordered, due to control dependencies. Not emitting the
> condition and maybe not even emitting the load completely wrecks this.
>
> Its therefore an invalid optimization to take out the conditional or
> speculate the store, since it takes out the dependency.
>