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]

3.0 -finline-limit and c++


I had a look about strange inlining behavior I reported couple of weeks
back.

It seems that the following code in cp/optimize.c:inlinable_function_p:

  if ((DECL_NUM_STMTS (fn) + id->inlined_stmts) * INSNS_PER_STMT 
      > MAX_INLINE_INSNS)
    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?

Teemu


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