Re: Optimizer options with autotools and CMake?

[Evan Huus <eapache () gmail com>]

On Sun, Aug 3, 2014 at 1:40 PM, Guy Harris <guy () alum mit edu> 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.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe