Signed overflow optimization hazards in the kernel [LWN.net]

Signed overflow optimization hazards in the kernel

Posted Aug 16, 2012 21:53 UTC (Thu) by daglwn (guest, #65432)
In reply to: Signed overflow optimization hazards in the kernel by gmaxwell
Parent article: Signed overflow optimization hazards in the kernel

Bingo. This is also why it's particularly bad to use unsigned loop counters.

to post comments

Signed overflow optimization hazards in the kernel

Posted Aug 16, 2012 22:19 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (2 responses)

So the kernel's current use of -fno-strict-overflow is presumably disabling a number of optimizations. How much performance would you two guess that the kernel is giving up?

Signed overflow optimization hazards in the kernel

Posted Aug 16, 2012 22:45 UTC (Thu) by gmaxwell (guest, #30048) [Link] (1 responses)

It's hard to say—

First, for code in the kernel, I assume that vectorizing is off the table because IIRC the kernel doesn't normally use the XMM registers to avoid saving them... so thats a chunk of the benefit that wouldn't exist in the kernel.

Branch prediction is often effective enough to make the looping cost small. But not always. I've seen easily measurable gains in numerical code performance just from reorganizing things so the compiler could find limits and unroll, but it doesn't always matter.

The most obvious thing to do would be to compile the kernel without the switches and hope that it runs long enough to run a few benchmarks. :)

Another issue is that overflow is _usually_ a bug where it exists (Yes, there are plenty of times where a programmer is using it intentionally but they are far less common than cases where an overflow is a bug). By preferring to use signed values and preventing overflow where you won't handle it, and using unsigned only where you must for range or where you intend overflow you make tools that catch bugs with dynamic instrumentation of overflow far more powerful. ( E.g. http://embed.cs.utah.edu/ioc/ ). Though since no one is applying these sorts of tools to the kernel I guess it doesn't matter currently. :)

Signed overflow optimization hazards in the kernel

Posted Aug 18, 2012 17:20 UTC (Sat) by ppisa (subscriber, #67307) [Link]

It would worth to compile and run kernel for MIPS with GCC option -ftrapv, if its actual GCC implementation is not broken in the current GCC version. MIPS has wrapping (addu, addiu) and signed overflow generation (add, addi) variants of the instructions. But wrapping variants are used even for signed types to keep compatibility with usual C code writeup manners.