Re: Inlining heuristics for C++

[Daniel Berlin <dan@cgsoftware.com>]

"Timothy J. Wood" <tjw@omnigroup.com> writes:

> On Monday, July 9, 2001, at 06:46  PM, Daniel Berlin wrote:
> [...]
>> We proceed to recursively inline 128 functions into this simple main
>> function
>> operator call. (Bet you didn't think there were 128 functions you could
>> inline here)
> 
>    IMO, the bug here is that the library you are using declares too
> many inlines.  I (personally) believe that 'inline' should be a
> command, not a request, and that a warning should be issued if
> inlining fails for some reason.  If you have the compiler decide to
> not inline stuff that is marked inline, then someone is going to come
> up with a case where they really need the inline where you didn't let
> them have it.  Then there will ensue a bunch of flags for controlling
> the inline limits and you're back to the programmer deciding when
> things should be inlined, but through a clumsier interface.  Or worse
> yet, they'll start using macros to get around the limits.
> 
> 
> 
> [...]
>> This is effectively expressing the rule: "Small functions should be
>> inlined into larger ones.  Larger functions should not be inlined into
>> small ones".
> 
> 
>    This rule is not true in general.  Just one example off the top of
> my head would be a case where you define a general inline function for
> performing some algorithm where some of the arguments are constants
> and you then define other 'real' functions that effectively pass
> configuration parameters (expecting the optimizer to treat them as
> constants and toss out different dead code in each case).
> 
> 
>    A silly little example might be:
> 
> static inline void generalCase(enum type t, enum operation op, ...)
> {
>      if (t == type1 || t == type3) {
> 	if (op == op1)
> 		block1;
> 	else
> 		block2;
>     } else if (t == type2 && op == op1) {
> 	block3;
>     }
> 	....
>}
> 
> 
> void t1op1(...)
> {
> 	generalCase(type1, op1, ...);
>}
> 
> void t2op2(...)
> {
> 	generalCase(type2, op2, ...);
>}
> 
> 
>    With this approach, you can often avoid needless duplication of
> code in the general case and can 'instantiate' the general case in
> each specific context and should be able to expect the compiler to
> blow away cases that can't be executed based on the inputs.

However, whatever calls t1op1 and t2op2 would recursively inline
generalcase, since generalcase is not as large as it.
It's the t1op1 and t2op2 compilations themselves that shouldn't have
general case inlined. You gain nothing.
If the calls to t1op1 and t2op2 were outside teh translation unit,
you'd be screwed anyway.
So i haven't reduced performance, just code size.

It's the *root* of the current inlining tree that we are comparing
relative to.
If it's t1op1 at the root, we shouldn't inline.
If it's something calling t1op1, we should inline both.

> 
>    Not only can make your code simpler, but you might have a couple
> common case that will perform better by having removed many of the
> branches from the general case.
> 
>    But, it is definitely the case, that the inlined function can be
> bigger than the function it is getting inlined into (which could just
> be a call to the inline!)
> 
> 
> -tim

-- 
"My watch is three hours fast, and I can't fix it.  So I'm going
to move to New York.
"-Steven Wright