This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [isocpp-parallel] Proposal for new memory_order_consume definition
- From: Michael Matz <matz at suse dot de>
- To: Linus Torvalds <torvalds at linux-foundation dot org>
- Cc: Markus Trippelsdorf <markus at trippelsdorf dot de>, Paul McKenney <paulmck at linux dot vnet dot ibm dot com>, "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>, parallel at lists dot isocpp dot org, llvm-dev at lists dot llvm dot org, Will Deacon <will dot deacon at arm dot com>, Linux Kernel Mailing List <linux-kernel at vger dot kernel dot org>, David Howells <dhowells at redhat dot com>, Peter Zijlstra <peterz at infradead dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Luc Maranget <luc dot maranget at inria dot fr>, Andrew Morton <akpm at linux-foundation dot org>, Jade Alglave <j dot alglave at ucl dot ac dot uk>, Ingo Molnar <mingo at kernel dot org>
- Date: Mon, 29 Feb 2016 18:37:02 +0100 (CET)
- Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition
- Authentication-results: sourceware.org; auth=none
- References: <20160218011033 dot GA1505 at linux dot vnet dot ibm dot com> <20160220021516 dot 4898897 dot 32908 dot 5212 at gmail dot com> <20160220195318 dot GF3522 at linux dot vnet dot ibm dot com> <CAPUmR1bw=N4NkjAK1zn_X0+84KEaEAM6HZCHZJy_txqC9hMgSg at mail dot gmail dot com> <20160227170615 dot GU3522 at linux dot vnet dot ibm dot com> <CA+55aFyHmykKc=YybJMo9ZUO352MY5noJVB4-K1Lkjmw4UHXfA at mail dot gmail dot com> <20160227231033 dot GW3522 at linux dot vnet dot ibm dot com> <20160228082702 dot GA300 at x4> <CA+55aFyauwKmUdxfrKcy5Q2kvdej5fWt6xL+amVyPFhzmHMcsg at mail dot gmail dot com>
Hi,
On Sun, 28 Feb 2016, Linus Torvalds wrote:
> > So the kernel obviously is already using its own C dialect, that is
> > pretty far from standard C. All these options also have a negative
> > impact on the performance of the generated code.
>
> They really don't.
They do.
> Have you ever seen code that cared about signed integer overflow?
>
> Yeah, getting it right can make the compiler generate an extra ALU
> instruction once in a blue moon, but trust me - you'll never notice.
> You *will* notice when you suddenly have a crash or a security issue
> due to bad code generation, though.
No, that's not at all the important piece of making signed overflow
undefined. The important part is with induction variables controlling
loops:
short i; for (i = start; i < end; i++)
vs.
unsigned short u; for (u = start; u < end; u++)
For the former you're allowed to assume that the loop will terminate, and
that its iteration count is easily computable. For the latter you get
modulo arithmetic and (if start/end are of larger type than u, say 'int')
it might not even terminate at all. That has direct consequences of
vectorizability of such loops (or profitability of such transformation)
and hence quite important performance implications in practice. Not for
the kernel of course. Now we can endlessly debate how (non)practical it
is to write HPC code in C or C++, but there we are.
> The fact is, undefined compiler behavior is never a good idea. Not for
> serious projects.
Perhaps if these undefinednesses wouldn't have been put into the standard,
people wouldn't have written HPC code, and if that were so the world would
be a nicer place sometimes (certainly for the compiler). Alas, it isn't.
Ciao,
Michael.