This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -Os is weak...

On Fri, Sep 10, 2010 at 10:44:24AM +0200, Steven Bosscher wrote:
> On Thu, Sep 9, 2010 at 6:43 PM, DJ Delorie <> wrote:
> I guess the most important missing optimizations are various forms of
> code unification, such as the sequence abstraction code that GCC used
> to have (, 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",

Was CFO finally merged to mainline?  At least, I can't find it in
current gcc.

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

We, Linaro Toolchain Working Group, are doing the investigation on
code size improvements on thumb-2.  As you said, there would be a lot of
room for improvement, and here is the report we got, fyi.

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

During the investigation, I feel that all the potential improvements
are identified by ARM experts or by reading asm code manually.  This
mode doesn't scale very well.  IMO, it is necessary to have a
target-independent framework for code size optimization.  I have no
idea to do that framework though.

Yao Qi
(650) 331-3385 x739

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]