Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1345343

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

Show all headers | View raw

On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
>> >
>> >   -fno-strict-overflow
>>
>>   -fno-strict-aliasing.
>
> Do not forget -fno-delete-null-pointer-checks.
>
> 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.

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.

The idiotic C alias rules aren't even worth discussing. They were a
mistake. The kernel doesn't use some "C dialect pretty far from
standard C". Yeah, let's just say that the original C designers were
better at their job than a gaggle of standards people who were making
bad crap up to make some Fortran-style programs go faster.

They don't speed up normal code either, they just introduce undefined
behavior in a lot of code.

And deleting NULL pointer checks because somebody made a mistake, and
then turning that small mistake into a real and exploitable security
hole? Not so smart either.

The fact is, undefined compiler behavior is never a good idea. Not for
serious projects.

Performance doesn't come from occasional small and odd
micro-optimizations. I care about performance a lot, and I actually
look at generated code and do profiling etc. None of those three
options have *ever* shown up as issues. But the incorrect code they
generate? It has.

     Linus

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [isocpp-parallel] Proposal for new memory_order_consume  definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-27 18:10 +0100
  Re: [isocpp-parallel] Proposal for new memory_order_consume  definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-28 00:20 +0100
    Re: [isocpp-parallel] Proposal for new memory_order_consume  definition Markus Trippelsdorf <markus@trippelsdorf.de> - 2016-02-28 09:30 +0100
      Re: [isocpp-parallel] Proposal for new memory_order_consume definition Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-28 17:20 +0100
        Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition cbergstrom@pathscale.com - 2016-02-28 18:00 +0100
        Re: [isocpp-parallel] Proposal for new memory_order_consume  definition Michael Matz <matz@suse.de> - 2016-02-29 18:40 +0100
          Re: [isocpp-parallel] Proposal for new memory_order_consume definition Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-29 19:00 +0100
        Re: [isocpp-parallel] Proposal for new memory_order_consume definition Lawrence Crowl <Lawrence@Crowl.org> - 2016-02-29 20:40 +0100
          Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume  definition James Y Knight <jyknight@google.com> - 2016-02-29 22:20 +0100
        Re: [isocpp-parallel] Proposal for new memory_order_consume  definition Toon Moene <toon@moene.org> - 2016-02-29 22:40 +0100
  Re: [isocpp-parallel] Proposal for new memory_order_consume  definition Michael Matz <matz@suse.de> - 2016-02-29 19:20 +0100
    Re: [isocpp-parallel] Proposal for new memory_order_consume  definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-03-01 02:30 +0100

csiph-web