This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Improving GCC8 default option settings
> On 14 Sep 2017, at 3:06 AM, Allan Sandfeld Jensen <linux@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.Dijkstra@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.