[LLVMdev] current llvm vs. current gcc code size

John Regehr regehr at cs.utah.edu
Sat Aug 23 12:09:52 PDT 2008

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 

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


More information about the llvm-dev mailing list