> 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.

Reply via email to