On Dec 31, 2006, at 19:13, Daniel Berlin wrote:
Note the distinct drop in performance across almost all the benchmarks on Dec 30, including popular programs like bzip2 and gzip.
Not so.
To my eyes, the specint 2000 mean went UP by about 1% for the base -O3 compilation. The peak enabled more unrolling, which is helped by additional range information provided by absence of -frwapv. So, I'd say this run would suggest enabling -fwrapv for at least -O1 and -O2. Also, note that we never have focussed on performance with -fwrapv, and it is quite likely there is quite some improvement possible. I'd really like using -fwrapv by default for -O, -O[s12]. The benefit of many programs moving from "undefined semantics" to "implementation-defined semantics, overflow wraps like in old compilers" far outweighs even an average performance loss of 2% as seen in specfp. As undefined execution can result in arbitrary badness, this is really at odds with the increasing need for many programs to be secure. Since it is almost impossible to prove that programs do not have signed integer overflow, it makes far more sense to define behavior in such cases. Note that were talking defaults: for not-so-sophisticated programmers, we should focus on being safe. People smart enough to proof their program can't cause signed integer overflow, can certainly figure out compiler options to disable -fwrapv. -Grt
