CMakeLists.txt forces -O2 to optimization flags

[janhubicka]

The following bits:

Force build with optimizations in release mode.

set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -O2")

Also optimize debug build; this is "unofficial", so it goes through ENV

if(DEFINED ENV{JPEGXL_OPT_DBG})
# Not the same thing as release_with_debug
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O2")
endif()

force -O2 to compiler flags even if user asks for different. Both GCC and Clang benefits from using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811 (by about 15% for GCC and 9% for clang.

I think image encoding is typical candidate for -O3 or -Ofast optimization level and also I think there should be way for user to change it.

[Traneptora]

-Ofast can break things. Particularly things with simd. (It's known to break zimg, for example.) -O3 is much safer, but doesn't always make code faster. See: https://wiki.gentoo.org/wiki/GCC_optimization#-O

[thesamesam]

-Ofast can break things. Particularly things with simd. (It's known to break zimg, for example.) -O3 is much safer, but doesn't always make code faster. See: wiki.gentoo.org/wiki/GCC_optimization#-O

The person you're replying to is one of the senior GCC maintainers.

[birdie-github]

-Ofast can break things. Particularly things with simd. (It's known to break zimg, for example.) -O3 is much safer, but doesn't always make code faster. See: https://wiki.gentoo.org/wiki/GCC_optimization#-O

As far as I understand this bug report is not about your choice of -O [optimization levels].

It's about the fact that you enforce them despite what people specify at build time.

I could be wrong.

[janhubicka]

GCC defines -O2 as the optimization level fit to build most packages in the distribution. So it does optimizations that does not trade too much of code size for speed. Getting everything twice as big to squeeze few cycles out of internal loops is not a good idea.

-O3 is for CPU bound code. Encoding/decoding graphics fits to the -O3 category well (and benchmark on the GCC PR I listed shows 15% speedup on encoding that is nice).

Clang has -O2 tuned for more code size growthand those who care use -Os. There is still noticeable speedup for -O3 at clang, too.

-Ofast enables -ffast-math and relaxes assumptions about memory model to allow more vectorization.
For math it does: -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans, -fcx-limited-range and -fexcess-precision=fast.
I do not know enough about jpegxl to tell if that could make difference. But if there is a good testsuite it should be easy to check if it affects output and why.

[janhubicka]

So in short - I think -O3 would be better default and also there should be way for user to change the default.

[sboukortt]

Thank you for this report. As of #2987, which has just been merged, we don’t force -O2 anymore.