[LLVMdev] current llvm vs. current gcc code size
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