CODEWITHSUNDEEP
c++cmakecompiler-flags
einpoklum
einpoklum

Reputation: 132128

Can I avoid explicitly specifying compiler flags to get a well-optimized build?

Suppose I have a CMake project which produces a CPU-intensive application.

When I build binaries for execution on a given machine, or for performance benchmarking, I would like them to be maximally, or at least heavily, optimized for speed. Of course, some optimizations are trade-offs, which don't always improve performance, but I mean optimizations which are considered "normally good enough" to apply universally, i.e. to apply to a program without having profiled it; for example, for GCC these would be flags like -O3 -march=native and maybe others.

Now, as I browse the CMake documentation, I don't quite find a guarantee that anything like this will be done for me, if I use the Release build type.

I could, of course, set the CMAKE_<LANG>_FLAGS_RELEASE variable, which in my specific case would be CMAKE_CPP_FLAGS_RELEASE. But - I would then need to:

and based on that - and knowledge of which compilers offer what kind of optimizations and how to enable them - I could set those flags, e.g. in an auxiliary module.

But - none of these settings is specific to my project and the program I'm compiling. I wonder why CMake doesn't do this for us...

Anyway, if we cannot leave things to CMake's care - what is a general(ish), idiomatic, hopefully widely-used approach to enable "full" optimizations in CMake, for many compilers and across multiple platforms?

Upvotes: 3

Views: 162

Answers (1)

Useless
Useless

Reputation: 67802

Why doesn't CMake offer to do this for me?

Well, CMake can't do this for you. Nobody can, in general.

The optimal build flags can change with compiler updates, hardware updates, and simple code changes.

The only way to find the optimal flags is to run automated performance benchmarks of your own real code, in a clean lab environment, using every hardware platform, compiler revision, and combination of flags you can think of. That's not really within the remit of a build configuration tool.

If you're actually going to be satisfied with -O3 -march=native (or the equivalent for other platforms), then that's both fairly easy to do and, potentially, a long way from maximal optimization.

There's another, probably equivalent way of looking at this.

Everybody thinks that the level of optimization they need is a reasonable default that should be built into the tooling, and that anyone who needs more specific flags is an exotic edge case.

That doesn't mean that any two of a given sample will actually agree on what this reasonable default is. If it were easy, there wouldn't be so many flags in the first place.

Upvotes: 6

Related Questions