[LLVMdev] current llvm vs. current gcc code size

[John Regehr]

On Fri, 22 Aug 2008, Dale Johannesen wrote:

> This is interesting.  Nobody has tried very hard to get -Os to work well 
> AFAIK, so it's that not surprising it doesn't:)  Aside from optimization 
> knobs, I don't think there's anything in x86 instruction selection to pick 
> small code sequences, which can be important.

Yeah.  In my view on x86 -Os should mainly boil down to keeping loop 
unrolling and function inlining under tight control.

Unrolling is pretty easy (don't do it) but inlining is tricky since 
limited inlining can significantly reduce code size, for some inputs.  Of 
course if you go too far there's major bloat.

I find LLVM's inlining heuristics to be pretty ad hoc.  There is an easy, 
more-or-less principled way to minimize code size using inlining, if you 
can see the whole program.  For each function, inline all calls to it if

   (s-o)(c-1) < x

where s is the estimated size of the function, o is the size overhead of 
the calling convention, c is the number of static callsites, and x is a 
magic parameter that tries to account for the fact that often there are 
added benefits to inlining because it enables subsequent intraprocedural 
optimizations.  x can be chosen empirically.  Of course this model of 
code bloat can be extended in any number of ways but it's pretty good 
as-is.

To the extent that LLVM becomes a compiler of choice for embedded 
processors, -Os will be important in the long run.

John