Re: Crucial C++ inlining broken under -Os

[Jan Hubicka <hubicka at ucw dot cz>]

> Quoting Jan Hubicka <hubicka@ucw.cz>:
>
>> The behaviour change is about COMDAT functions that are larger than call
>> overhead but either called just once or small enough so code growth caused
>> by inlining is smaller than the function body size itself.  In these cases
>> we made the assumption that overall program size will change and inlined
>> in previous GCC releases.
>
> I.e., we assumed that the number of TU this function was used was 1.

Yes, we assumed that all COMDAT functions was static and thus somewhat
defeating purpose of COMDAT at first place.
>
>> This asusmption is not correct (it is correct for static functions   
>> and also for
>> size of .o file, but not for whole binary) and the problem can be   
>> demonstrated
>> by making very large comdat function that is used once in very many units.
>> Thus I've changed the behaviour in GCC 4.5 since it is more safe.
>
> It seems to be equivalent to assume the number of TU this function is used
> in is infinity.
>
> How about a parameter for the number of TU we guess the function will be
> needed in?

You are interested in amount of call sites for specific function, having
some generic measurement like "usual comdat function is called 300 times
on Mozilla build" won't help you, since setting this argument for 2 and
more would disable most of inlining again.

There are cases where function called twice is still inlined since offline
copy + expected benefit compensates the caller size growth, but it is
rather rare.

Honza