Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#38218 closed enhancement (fixed)

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

Reported by: jeremyhu (Jeremy Huddleston Sequoia) Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 2.2.0
Component: base Version: 2.1.3
Keywords: Cc: ryandesign (Ryan Schmidt), skymoo (Adam Mercer), potmj
Port:

Description

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)

Change History (14)

comment:1 Changed 6 years ago by 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.

comment:2 Changed 6 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added
Milestone: MacPorts Future
Summary: default optflags should be -Os rather than -O2default configure.optflags should be -Os rather than -O2

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.

comment:3 Changed 6 years ago by ryandesign (Ryan Schmidt)

Type: defectenhancement

comment:4 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:5 in reply to:  2 Changed 6 years ago by potmj

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 ​#37839

Last edited 6 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:6 Changed 6 years ago by skymoo (Adam Mercer)

Cc: ram@… added

Cc Me!

comment:7 Changed 6 years ago by ryandesign (Ryan 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.

comment:8 Changed 6 years ago by ryandesign (Ryan Schmidt)

Cc: fmw@… added

comment:9 Changed 6 years ago by jmroot (Joshua Root)

Sounds fine to me.

comment:10 in reply to:  7 Changed 6 years ago by ryandesign (Ryan 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"}.

comment:11 in reply to:  description Changed 6 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: newclosed

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.

comment:12 in reply to:  description Changed 6 years ago by 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.

comment:13 Changed 6 years ago by 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.

comment:14 Changed 6 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 2.2.0
Note: See TracTickets for help on using tickets.