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: Torvald Riegel <triegel at redhat dot com>
- To: Linus Torvalds <torvalds at linux-foundation dot org>
- Cc: Paul McKenney <paulmck at linux dot vnet dot ibm dot com>, Will Deacon <will dot deacon at arm dot com>, Peter Zijlstra <peterz at infradead dot org>, 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: Tue, 18 Feb 2014 16:38:40 +0100
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <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> <1392183564 dot 18779 dot 2187 dot camel at triegel dot csb> <20140212180739 dot GB4250 at linux dot vnet dot ibm dot com> <CA+55aFw3S82GYdtnV2nJCvBGcuZf6kXdF5b7Vp9yb21QKr49Jw at mail dot gmail dot com> <20140213002355 dot GI4250 at linux dot vnet dot ibm dot com> <1392321837 dot 18779 dot 3249 dot camel at triegel dot csb> <20140214020144 dot GO4250 at linux dot vnet dot ibm dot com> <1392352981 dot 18779 dot 3800 dot camel at triegel dot csb> <20140214172920 dot GQ4250 at linux dot vnet dot ibm dot com> <CA+55aFx9CbgrfK4rBVYD75y2KoWiO90dSYsAW83O-tYVLK-gkg at mail dot gmail dot com> <CA+55aFypfiTFwundih8QEA6ZwVGk=g5L4sabsN0932eih5knOQ at mail dot gmail dot com> <1392486310 dot 18779 dot 6447 dot camel at triegel dot csb> <CA+55aFwTrt_6m1inNHQkk74i7uPkHNnacwHiBgioZSXieAs5Sw at mail dot gmail dot com> <1392666947 dot 18779 dot 6838 dot camel at triegel dot csb> <CA+55aFwUnRVk6q3VZeYjWfduoHcExW=Pht6jgp=4bBSaLHNPMA at mail dot gmail dot com> <1392672063 dot 18779 dot 6940 dot camel at triegel dot csb> <1392675939 dot 18779 dot 7063 dot camel at triegel dot csb> <CA+55aFx2jxE8! sTZEmNnMg6ktDuU_0xPiEw3=qH0=+xat8p8cAA at mail dot gmail dot com> <1392680518 dot 18779 dot 7213 dot camel at triegel dot csb> <CA+55aFzSBZMC6kbdJj5Jus9-q1dzXdCYQXfMm34O+9h8SbGcGQ at mail dot gmail dot com>
On Mon, 2014-02-17 at 16:18 -0800, Linus Torvalds wrote:
> On Mon, Feb 17, 2014 at 3:41 PM, Torvald Riegel <triegel@redhat.com> wrote:
> >
> > There's an underlying problem here that's independent from the actual
> > instance that you're worried about here: "no sense" is a ultimately a
> > matter of taste/objectives/priorities as long as the respective
> > specification is logically consistent.
>
> Yes. But I don't think it's "independent".
>
> Exactly *because* some people will read standards without applying
> "does the resulting code generation actually make sense for the
> programmer that wrote the code", the standard has to be pretty clear.
>
> The standard often *isn't* pretty clear. It wasn't clear enough when
> it came to "volatile", and yet that was a *much* simpler concept than
> atomic accesses and memory ordering.
>
> And most of the time it's not a big deal. But because the C standard
> generally tries to be very portable, and cover different machines,
> there tends to be a mindset that anything inherently unportable is
> "undefined" or "implementation defined", and then the compiler writer
> is basically given free reign to do anything they want (with
> "implementation defined" at least requiring that it is reliably the
> same thing).
Yes, that's how it works in general. And this makes sense, because all
optimizations rely on that. Second, you can't keep something consistent
(eg, between compilers) if it isn't specified. So if we want stricter
rules, those need to be specified somewhere.
> And when it comes to memory ordering, *everything* is basically
> non-portable, because different CPU's very much have different rules.
Well, the current set of memory orders (and the memory model as a whole)
is portable, even though it might not allow to exploit all hardware
properties, and thus might perform sub-optimally in some cases.
> I worry that that means that the standard then takes the stance that
> "well, compiler re-ordering is no worse than CPU re-ordering, so we
> let the compiler do anything". And then we have to either add
> "volatile" to make sure the compiler doesn't do that, or use an overly
> strict memory model at the compiler level that makes it all pointless.
Using "volatile" is not a good option, I think, because synchronization
between threads should be orthogonal to observable output of the
abstract machine.
The current memory model might not allow to exploit all hardware
properties, I agree.
But then why don't we work on how to extend it to do so? We need to
specify the behavior we want anyway, and this can't be independent of
the language semantics, so it has to be conceptually integrated with the
standard anyway.
> So I really really hope that the standard doesn't give compiler
> writers free hands to do anything that they can prove is "equivalent"
> in the virtual C machine model.
It does, but it also doesn't mean this can't be extended. So let's
focus on whether we can find an extension.
> That's not how you get reliable
> results.
In this general form, that's obviously a false claim.