On Thu, Sep 9, 2010 at 6:43 PM, DJ Delorie <d...@redhat.com> wrote:
>
> The docs say...
>
> @item -Os
> @opindex Os
> Optimize for size. �...@option{-os} enables all @option{-O2} optimizations
> that
> do not typically increase code size. It also performs further
> optimizations designed to reduce code size.
>
> @option{-Os} disables the following optimization flags:
> @gccoptlist{-falign-functions -falign-jumps -falign-loops @gol
> -falign-labels -freorder-blocks -freorder-blocks-and-partition @gol
> -fprefetch-loop-arrays -ftree-vect-loop-version}
>
> But in reality, the only thing -Os does beyond -O2, aside from a few
> niche special cases, is enable inlining, and maybe scheduling, which
> for some cases may be the wrong thing to do.
>
> Is this what we want?
So yesterday I already sent out a few mails explaining that there is
really more than just the things you described above. It seems that
you haven't followed GCC development closely enough for a while to
notice that the "optimize_size" checks have mostly been replaced with
more fine-grained checks, even at the level of individual insns.
What you quote above, from the documentation, is also actually
incomplete. The -Os option also enables optimizations that are not
performed at -O[123], e.g. code hoisting only runs at -Os (see
gcse.c:pass_rtl_hoist).
That said, it is true that GCC does not have the strongest code size
optimizations compared to other compilers on the market. There are
many things GCC could do better/more to improve code size further.
This is a matter of focus, as you know: If no-one cares enough to
commit enough resources to code-size optimizations, they will not get
implemented in GCC.
I guess the most important missing optimizations are various forms of
code unification, such as the sequence abstraction code that GCC used
to have (http://gcc.gnu.org/projects/cfo.html, but it never worked
properly and it was way too slow), or some suffix-tree based sequence
finding code. Various algorithms can be found in the academic
literature about code size optimizations via abstraction (see e.g.
"Procedural Abstraction with Reverse Prefix Trees",
http://portal.acm.org/citation.cfm?id=1545074).
Even for the existing code size optimizations, improvements are
possible. I've played with some ideas myself, with new work
(implementing code hoisting for GIMPLE, xf.
http://gcc.gnu.org/PR23286) and extending other people's work
(if-conversion and cross-jumping, xf. http://gcc.gnu.org/PR20070). If
you have plans to work on improved -Os optimizations, those two could
be good starting points to warm up.
Personally, I had hoped that the ARM folks (Linaro, or what's it
called?) would work on -Os. While I've never actually used it, a web
search suggests that the RealView compilers generate code that is as
much as 20% smaller than GCC at -Os (for unnamed benchmarks), so
apparently there is a lot of room for improvement in GCC and the ARM
people should know where.
Finally, of course there are just various issues with instruction
selection in GCC that result in larger-than-necessary code. It seems
that this doesn't hurt code speed so much, but for code size GCC
doesn't always select the shortes sequence possible. Some Google folks
(Carrot Wei in particular) have filed bugs and patches for a couple of
cases for ARM, but there is no target-independent frame work for
selecting the shortest insn or sequence.
Is there a particular target you're interested in?
Ciao!
Steven
