cmake: Allow specifying optimization level in COMMON_OPT

[mmuetzel]

When building with make a default optimization level of -O2 is used. See: https://github.com/xianyi/OpenBLAS/blob/00534523ad999d89945d23b7df0eafc69c31f1b3/Makefile.system#L1551-L1557

By default, cmake uses -O3 for Release builds currently: https://github.com/Kitware/CMake/blob/v3.24.1/Modules/Compiler/GNU.cmake#L59

This means binaries are built with different optimization levels depending on whether make or cmake is used.

Additionally, it is currently not possible to override the optimization level with, e.g., -DCOMMON_OPT=-O2 because it appears before the CMAKE_${Language}_FLAGS_RELEASE flags (which effectively overrides the flag in COMMON_OPT).

See also: #3740

The proposed change sets the default compiler optimization level that is used with cmake to -O2 (i.e., the same that is used by make). Additionally, it allows overriding the compiler optimization level with flags in COMMON_OPT, CCOMMON_OPT, and FCOMMON_OPT.

[brada4]

Maybe it is worth playing warning, my rationale is that -Os has a practical purpose always when used, but say -Ofast guarantees numeric faults.

[mmuetzel]

Maybe it is worth playing warning, my rationale is that -Os has a practical purpose always when used, but say -Ofast guarantees numeric faults.

I'm not sure I understand your comment. The proposed change doesn't touch any flags supplied by the user in the COMMON_OPT variables. And I'd argue that this should stay as it is. The build system should assume that a user knows what they are doing when setting custom flags...

[brada4]

PR is not wrong, just that probably needs some discussion/consideration.

[mmuetzel]

PR is not wrong, just that probably needs some discussion/consideration.

I'm happy to discuss. But I don't understand which changes you are proposing.

[mmuetzel]

I'm not sure why one of the checks of this PR was failing: https://github.com/xianyi/OpenBLAS/runs/8095576089?check_suite_focus=true

IIUC, that check uses make to build OpenBLAS. Afaict, this PR doesn't touch the Makefile rules.

[martin-frbg]

I'm not sure why one of the checks of this PR was failing: Me neither, that cross-build check has been failing more or less randomly lately and I have not managed to reproduce this locally.

On the actual topic of your PR, I am unsure if it would be useful to change the well-defined CMAKE default behaviour for Release builds years after adding cmake support. Perhaps it might be more useful to just handle the case where the user declared no build type at all (as a novice user might), which currently would result in no -O option at all (I think) ?

[mmuetzel]

Afaict, it is not completely uncommon that projects override the flags in CMAKE_${Language}_FLAGS_${CMAKE_BUILD_TYPE}. But I understand your point of view. We could just remove the block that modifies these flags from the PR.

At the same time, it might be surprising for users if optimization flags that they pass with the COMMON_OPT variables don't actually have any effect. (At least, it was for me.)

Should the build rules check if there are any -O flags in the COMMON_OPT variables and remove them from cmake's default flags conditional on that? That would be possible. But it would be pretty involved (and maybe more error prone?).

[mmuetzel]

I updated the PR to leave cmake's default optimization level alone unless the user explicitly specifies optimization flags in any of the COMMON_OPT variables.

[brada4]

I think we set release_with_debuginfo for novice user case which roughly matches makefile behaviour. -frecursive is a paramount, it is obscure name for thread safety in fortran....