This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [c++std-parallel-1632] Re: Compilers and RCU readers: Once more unto the breach!
- From: "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- To: c++std-parallel at accu dot org
- Cc: Will Deacon <will dot deacon at arm dot com>, Linus Torvalds <torvalds at linux-foundation dot org>, Linux Kernel Mailing List <linux-kernel at vger dot kernel 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 11:16:47 -0700
- Subject: Re: [c++std-parallel-1632] 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> <20150520154617 dot GE11498 at arm dot com> <555CAE4B dot 4050202 at redhat dot com>
- Reply-to: paulmck at linux dot vnet dot ibm dot com
On Wed, May 20, 2015 at 04:54:51PM +0100, Andrew Haley wrote:
> On 05/20/2015 04:46 PM, Will Deacon wrote:
> > 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.
>
> It'd just convert consume to acquire.
It should not need to, actually.
Thanx, Paul