Remix.run Logo
201984 an hour ago

What's your reason for -O2 over -O3?

cogman10 an hour ago | parent | next [-]

Historically, -O3 has been a bit less stable (producing incorrect code) and more experimental (doesn't always make things faster).

Flags from -O3 often flow down into -O2 as they are proven generally beneficial.

That said, I don't think -O3 has the problems it once did.

sgerenser 29 minutes ago | parent | next [-]

-O3 gained a reputation of being more likely to "break" code, but in reality it was almost always "breaking" code that was invalid to start with (invoked undefined behavior). The problem is C and C++ have so many UB edge cases that a large volume of existing code may invoke UB in certain situations. So -O2 thus had a reputation of being more reliable. If you're sure your code doesn't invoke undefined behavior, though, then -O3 should be fine on a modern compiler.

201984 an hour ago | parent | prev [-]

Thanks

wavemode an hour ago | parent | prev | next [-]

You have to profile for your specific use case. Some programs run slower under O3 because it inlines/unrolls more aggressively, increasing code size (which can be cache-unfriendly).

grogers a few seconds ago | parent [-]

Yeah, -O3 generally performs well in small benchmarks because of aggressive loop unrolling and inlining. But in large programs that face icache pressure, it can end up being slower. Sometimes -Os is even better for the same reason, but -O2 is usually a better default.

bluGill 31 minutes ago | parent | prev [-]

Most people use -O2 and so if you use -O3 you risk some bug in the optimizer that nobody else noticed yet. -O2 is less likely to have problems.

In my experience a team of 200 developers will see 1 compiler bug affect them every 10 years. This isn't scientific, but it is a good rule of thumb and may put the above in perspective.

macintux 7 minutes ago | parent [-]

Would you say that bug estimate is when using -O2 or -O3?