> When compiling for SPARC using GCC 4.5.1 and the option -fwhole-program, > it seems that sometimes the decision to inline is not well taken since > the resulting code is bigger (I assume that when inline is applied the > objective is to reduce the size of the code and the number of executed > instructions). The goal depends on the optimization level. With -O3, it's only speed so inlining will generally increase code size, +20% isn't unusual. With -Os inlining should indeed avoid increasing code size. > The whole point seems to be the cost of the function parameters CP > (eventually the casts done in the caller) which are taken into account > in the size estimation only before the inlining and it seems that the > compilator believes that after the inline such casts are not going to be > done and therefore are not taken into account for the decision. However, > after the code compilation, such parameters are included anyway along > with the inlined code. Probably the volatileness, it may skew the size estimates. I'd suggest testing with less artificial examples. > I appreciate any feedback or suggestions you have about this, maybe I'm > doing it all wrong from the begining, but the fact that inline increases > the size of the code was weird to me. The inlining heuristics are complex and tuned for real programs, so it's probably easy to fool them with toy examples. Modifying them generally requires a lot of retuning efforts so isn't a small undertaking. -- Eric Botcazou
