default configure.optflags should be -Os rather than -O2

[jeremyhu (Jeremy Huddleston Sequoia)]

All the kids are doing it. -Os will result in smaller text allowing for more optimal use of spacial locality in the text cache. As an added benefit, ppc will benefit in areas where -O2 results in text segments that are too large for reloc (#37839)

[cooljeanius (Eric Gallager)]

I've had times where altering the optimization level would make my code fail to compile. We should test to make sure this won't break anything before we go changing anything.

[ryandesign (Ryan Carsten Schmidt)]

There's no practical way to test that this won't break "anything". We can change it in trunk now and see if we notice any problems on our development machines. And we'll probably let the buildbots rebuild all ports after this (since hopefully it'll go into 2.2 for which we already have to rebuild all ports because of the libtool archive changes) but looking through a log of building thousands of ports to analyze the ones that failed is impractical, especially given how many of our ports already don't build for other reasons. We can handle this like we always do: if people find ports that are broken, because of this or any other reason, they can file tickets and we'll fix them on a case-by-case basis.

[jeremyhu (Jeremy Huddleston Sequoia)]

And FWIW, the difference from -O2 to -Os is really a small set of safe optimizations.

[potmj (Michael Pot)]

Replying to ryandesign@…:

There's no practical way to test that this won't break "anything". We can change it in trunk now and see if we notice any problems on our development machines. And we'll probably let the buildbots rebuild all ports after this (since hopefully it'll go into 2.2 for which we already have to rebuild all ports because of the libtool archive changes) but looking through a log of building thousands of ports to analyze the ones that failed is impractical, especially given how many of our ports already don't build for other reasons. We can handle this like we always do: if people find ports that are broken, because of this or any other reason, they can file tickets and we'll fix them on a case-by-case basis.

Sorry in advance for not having much undrestanding of macports....

In the webkit-gtk portfile (which provoked this), I note the line "platform powerpc {". If this is only invoking options based on the compile time CPU, would a line like "target powerpc {" for the runtime CPU, be a base solution by providing a way of implementing patches and flags required when there is sometimes a difference between compile & execute CPUs? Moreover, such a facility might permit easy testing (or back tracking) before (after), a change like -Os goes live? This sort of facility is what I first went looking for when I found ​​https://trac.macports.org/ticket/37839

[skymoo (Adam Mercer)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

platform powerpc is syntactic sugar exactly equivalent to if {${os.platform} == "powerpc"}. There is no syntax target powerpc in MacPorts. We already have the ${configure.build_arch} and ${configure.universal_archs} variables which can be used to inspect the architecture(s) being built for. This ticket is only about the one-character change needed to change the default configure.optflags from -O2 to -Os. Anything else should be discussed elsewhere.

[jmroot (Joshua Root)]

Sounds fine to me.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

platform powerpc is syntactic sugar exactly equivalent to if {${os.platform} == "powerpc"}.

Correction: platform powerpc is syntactic sugar exactly equivalent to if {${os.arch} == "powerpc"}.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

All the kids are doing it.

Don't I recall that Apple switched to using -Os for the programs shipped in OS X some versions ago? Snow Leopard maybe? (Absolutely impossible to find "-Os" on Google of course.)

Changed in r103497.

[raimue (Rainer Müller)]

Replying to jeremyhu@…:

All the kids are doing it. -Os will result in smaller text allowing for more optimal use of spacial locality in the text cache.

I am not opposed to the change, but I just can't leave that statement uncommented :-)

I don't think -Os is always the better choice under all circumstances. There was a recent discussion on enabling ​-Os for the Linux kernel and it was turned down, although that is about gcc whereas we are mostly using clang now.

For clang the man page states:

-Os is like -O2 with extra optimizations to reduce code size.

I would say this is misleading. -Os is like -O2, but excludes optimizations that would cause the code size to grow. For example, it might disable inlining for larger functions and therefore, code locality can actually be decreased by -Os.

[jmroot (Joshua Root)]

Is that actually true for clang? The gcc man page has a more detailed explanation of what the optimisation levels do, and also mentions -Oz, which "enables other optimizations intended solely to reduce code size" and is "very similar to -Os in FSF distributions of GCC". Clang could be doing any combination of the things selected by either of these levels in GCC, or more.