This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 3.3 release criteria


On Wednesday, February 26, 2003, at 06:57 AM, Robert Dewar wrote:
A common coding style (at least around here) is to write rather big
and complex inline functions (frequently containing calls to other big
inline functions), assuming that they will collapse to relatively
little code when instantiated, because of constant folding and
dead-code removal. Quite often the resulting code is smaller than the
function call to a non-inlined function.

Indeed that is a common style, and I would say that if the compiler does
not inline in such a case, then even if the inline keyword is advisory,
this would seem to be a bug!

If people in C land are complaining that C doesn't inline enough, and have not complained that it does it too much, then obviously this is a compiler bug and C should inline more. There isn't a reason that C and C++ have to use the same exact heuristics.


What I do know, is that it did inline too much in C++ when confronted with default inline template code, and that we should not undo this for C++.

Can we just bump up the heuristic for C by, say 10x and see how people like it. If they don't complain, and the people that used to complain about C stop, then that _is_ a better choice. If 10x is too small, how about 100x?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]