Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

1. that's good to know. I'm all for shortening my cflags line since I don't squelch my Makefile rules.

2. I always get bitten when I try and generalize. I tested this in all of my software, and was not able to detect any performance difference with or without -fwrapv (that is to say, < 1% difference, too small of a difference to make any conclusions.)

I know you can create extreme edge cases where there's a huge difference, just as you can probably make up one that's slower without -fwrapv if you really wanted to.

But yeah, maybe I just don't write code that lends itself to benefiting heavily from these types of assumptions. I also tend to not really rely on signed integer overflow following twos-complement. But all the same, I will take well-defined behavior over the crazy stuff GCC can produce any day, even at the cost of a bit of performance. Of course, going all the way to -O0 is way too extreme. So a case where I see no perceptible performance impact and gain defined behavior? Win-win.



2. You must not write software very amenable.

Fun fact btw: GCC and LLVM are the only compilers I know of to assume loops can overflow at all when optimizations are on.

Compilers like XLC will actually even assume unsigned loop induction variables will not ovefrlow at O3, unless you give them special flags.

:)


> Compilers like XLC will actually even assume unsigned loop induction variables will not ovefrlow at O3

That's not exactly fair. The C standard guarantees that unsigned variables will overflow by wrapping, so if the compiler assumes such a loop won't terminate, it is not conformant.


That's exactly the point: they cheat, because it makes code faster except in the small percent of code it breaks.

Let us all now bow our heads to the almighty SPEC gods ...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: