This is the mail archive of the
mailing list for the GCC project.
Re: Overwhelmed by GCC frustration
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: Eric Gallager <egall at gwmail dot gwu dot edu>, Jakub Jelinek <jakub at redhat dot com>, Andrew Haley <aph at redhat dot com>, Oleg Endo <oleg dot endo at t-online dot de>, Georg-Johann Lay <avr at gjlay dot de>, GCC Development <gcc at gcc dot gnu dot org>, nd at arm dot com
- Date: Wed, 2 Aug 2017 10:11:36 +0200
- Subject: Re: Overwhelmed by GCC frustration
- Authentication-results: sourceware.org; auth=none
- References: <597F2FB4.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <CAFiYyc2nPd18jEcUfQnf4UXOm4WTcS2RVMnMbs1+ezKWD_5obA@mail.gmail.com> <CAMfHzOtL1XdmJa4GnfH5FCKN3QZpzv1CJazOWfbavw2iOrFkKQ@mail.gmail.com> <20170801112223.GW2123@tucnak> <CAMfHzOtA6Lv6RUu1XE8GqPT=KUxvaKxm-4eYf_VE59o_tf=GCQ@mail.gmail.com> <20170801160022.GA34547@arm.com>
On Tue, Aug 1, 2017 at 6:00 PM, James Greenhalgh
> On Tue, Aug 01, 2017 at 11:12:12AM -0400, Eric Gallager wrote:
>> On 8/1/17, Jakub Jelinek <email@example.com> wrote:
>> > On Tue, Aug 01, 2017 at 07:08:41AM -0400, Eric Gallager wrote:
>> >> > Heh. I suspect -Os would benefit from a separate compilation pipeline
>> >> > such as -Og. Nowadays the early optimization pipeline is what you
>> >> > want (mostly simple CSE & jump optimizations, focused on code
>> >> > size improvements). That doesn't get you any loop optimizations but
>> >> > loop optimizations always have the chance to increase code size
>> >> > or register pressure.
>> >> >
>> >> Maybe in addition to the -Os optimization level, GCC mainline could
>> >> also add the -Oz optimization level like Apple's GCC had, and clang
>> >> still has? Basically -Os is -O2 with additional code size focus,
>> >> whereas -Oz is -O0 with the same code size focus. Adding it to the
>> >> FSF's GCC, too, could help reduce code size even further than -Os
>> >> currently does.
>> > No, lack of optimizations certainly doesn't reduce the code size.
>> > For small code, you need lots of optimizations, but preferrably code-size
>> > aware ones. For RTL that is usually easier, because you can often compare
>> > the sizes of the old and new sequences and choose smaller, for GIMPLE
>> > optimizations it is often just a wild guess on what optimizations generally
>> > result in smaller and what optimizations generally result in larger code.
>> > There are too many following passes to know for sure, and finding the right
>> > heuristics is hard.
>> > Jakub
>> Upon rereading of the relevant docs, I guess it was a mistake to
>> compare -Oz to -O0. Let me quote from the apple-gcc "Optimize Options"
>> (APPLE ONLY) Optimize for size, regardless of performance. -Oz
>> enables the same optimization flags that -Os uses, but -Oz also
>> enables other optimizations intended solely to reduce code size.
>> In particular, instructions that encode into fewer bytes are
>> preferred over longer instructions that execute in fewer cycles.
>> -Oz on Darwin is very similar to -Os in FSF distributions of GCC.
>> -Oz employs the same inlining limits and avoids string instructions
>> just like -Os.
>> Meanwhile, their description of -Os as contrasted to -Oz reads:
>> Optimize for size, but not at the expense of speed. -Os enables all
>> -O2 optimizations that do not typically increase code size.
>> However, instructions are chosen for best performance, regardless
>> of size. To optimize solely for size on Darwin, use -Oz (APPLE
>> And the clang docs for -Oz say:
>> -Oz Like -Os (and thus -O2), but reduces code size further.
>> So -Oz does actually still optimize, so it's more like -O2 than -O0
>> after all, just even more size-focused than -Os.
> The relationship between -Os and -Oz is like the relationship between -O2
> and -O3.
> If -O3 says, try everything you can to increase performance even at the
> expense of code-size and compile time, then -Oz says, try everything you
> can to reduce the code size, even at the expense of performance and
> compile time.
Note for GCC -Os has been this historically. I'd say that compared to
other compilers -O2 is what they do at -Os -- balance speed and size
with GCC being much more conservative on the size side than other
compilers. Recently we've "weakened" -Os by for example allowing
integer division to expand to mul/add sequences but IIRC that was based
on the costs the target provides.