Wireshark · Wireshark-dev: Re: [Wireshark-dev] Optimizer options with autotools and CMake?

[Evan Huus <eapache@xxxxxxxxx>]

On Sun, Aug 3, 2014 at 1:40 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

I've noticed, on occasion, that sometimes the CMake builds on the UN*X buildbots get warnings that the autotools builds don't.

Recently, I tried to figure out what was different about the CMake builds; after some fixes that removed some incorrect differences between them, I eventually stumbled across the way to get CMake to produce makefiles that did verbose builds, printing the compile command as part of the build output, and found that the difference was very simple - autotools builds weren't building with a -O option, while CMake builds were building with -O2.

I could have sworn my autotools builds used -O2... *goes to check*

Yup, my master-1.12 vanilla autotools build adds -O2 to CFLAGS and CXXFLAGS. I don't have a master autotools build handy, but I can't recall any changes that would have affected that...

 

The optimizer is what does some, if not all, of the dataflow analysis that produces "use before set" warnings, so those warnings were showing up on the CMake builds but not the autotools builds.

So:

        Is there any reason not to do whatever is necessary to use a -O option on the autotools builds?  In addition to getting extra warnings from optimized builds, we also presumably want optimized code in the binaries we ship, and want to at least require third-party packagers to explicitly decide *not* to ship optimized code.

        Should we use -O2, -Os, or some other option (for both autotools *and* CMake)?  The GCC 4.9.1 manual says of -O2

"Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. As compared to -O, this option increases both compilation time and the performance of the generated code."

        and of -Os:

"Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.

-Os disables the following optimization flags:

          -falign-functions  -falign-jumps  -falign-loops
          -falign-labels  -freorder-blocks  -freorder-blocks-and-partition
          -fprefetch-loop-arrays"

        and the Clang manual at

                http://clang.llvm.org/docs/UsersManual.html

        says, err, umm, nothing useful, because it really sucks at documenting command-line options.

I vote that:
1. In development (i.e. the default when getting the git repository) we default to -Og for compilers which support it. The GCC 4.9.1 manual says:

"Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience."

And fall back to -O2 when the compiler does not support -Og (older versions of GCC... I dunno about clang).

2. In release builds (including source tarballs and buildbots) we default to -O2.