> On 14 Sep 2017, at 3:06 AM, Allan Sandfeld Jensen <li...@carewolf.com> wrote: > > On Dienstag, 12. September 2017 23:27:22 CEST Michael Clark wrote: >>> On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra <wilco.dijks...@arm.com> wrote: >>> >>> Hi all, >>> >>> At the GNU Cauldron I was inspired by several interesting talks about >>> improving GCC in various ways. While GCC has many great optimizations, a >>> common theme is that its default settings are rather conservative. As a >>> result users are required to enable several additional optimizations by >>> hand to get good code. Other compilers enable more optimizations at -O2 >>> (loop unrolling in LLVM was mentioned repeatedly) which GCC could/should >>> do as well. >> >> There are some nuances to -O2. Please consider -O2 users who wish use it >> like Clang/LLVM’s -Os (-O2 without loop vectorisation IIRC). >> >> Clang/LLVM has an -Os that is like -O2 so adding optimisations that increase >> code size can be skipped from -Os without drastically effecting >> performance. >> >> This is not the case with GCC where -Os is a size at all costs optimisation >> mode. GCC users option for size not at the expense of speed is to use -O2. >> >> Clang GCC >> -Oz ~= -Os >> -Os ~= -O2 >> > No. Clang's -Os is somewhat limited compared to gcc's, just like the clang > -Og > is just -O1. AFAIK -Oz is a proprietary Apple clang parameter, and not in > clang proper.
It appears to be in mainline clang. mclark@anarch128:~$ clang -Oz -c a.c -o a.o mclark@anarch128:~$ clang -Ox -c a.c -o a.o error: invalid integral value 'x' in '-Ox' error: invalid integral value 'x' in '-Ox' mclark@anarch128:~$ uname -a Linux anarch128.org 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux mclark@anarch128:~$ clang --version clang version 3.8.1-24 (tags/RELEASE_381/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin I still think it would be unfortunate to loose the size/speed sweet spot of -O2 by adding optimisations that increase code size, unless there was a size optimisation option that was derived from -O2 at the point -O2 is souped up. i.e. create an -O2s (or renaming -Os to -Oz and deriving the new -Os from the current -O2). I’m going to start looking at this point to see whats involved in making a patch. Distros want a balance or size and speed might even pick it up, even if it is not accepted in mainline.