This is the mail archive of the
mailing list for the GCC project.
3.0 -finline-limit and c++
- To: gcc at gcc dot gnu dot org
- Subject: 3.0 -finline-limit and c++
- From: Teemu Torma <tot at trema dot com>
- Date: Fri, 25 May 2001 13:23:11 +0200
I had a look about strange inlining behavior I reported couple of weeks
It seems that the following code in cp/optimize.c:inlinable_function_p:
if ((DECL_NUM_STMTS (fn) + id->inlined_stmts) * INSNS_PER_STMT
inlinable = 0;
causes that nothing will be inlined after the total insns in the current
inline contect is reached.
At least in my mind, this is not very desirable effect, and makes
-finline-limit quite useless, other than incresing the value even more
(the default is 10000 I think). By commenting the above code out, the
inlining works more what I would expect, -finline-limit limiting the
size of an inlinable function rather than context. With limit of 500 or
1000, I get reasonable inlining limits without huge compile time and
code size penalties, and still good optimization of the small functions.
Even though the idea of having limits on the inline context is nice, the
current behaviour is too simplistic and makes things worse. Maybe the
context limit should be another option, with a minimum limit that will
always be inlined no matter what, and starting the inlining with
smallest functions first.
But for 3.0, I would suggest taking off the inline context check, and
preferably reducing the default inline limit to 1000 or so to not
explode template code size and compilation time.
Does this make sense or am I revealing my ignorance here?