This is the mail archive of the
mailing list for the GCC project.
Re: bug introduced by inlining patch
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Kurt Garloff <garloff at suse dot de>
- Cc: Dale Johannesen <dalej at apple dot com>, gcc-patches at gcc dot gnu dot org,gcc at gcc dot gnu dot org
- Date: Wed, 4 Sep 2002 14:35:44 -0400
- Subject: Re: bug introduced by inlining patch
Once again, there is never a good reason to inline starting at the
leaves when you have good information like loop depth, estimated call
Next improvement would be to calculate the complete call graph
take decisions on where to cut it based on inlining limits, loop depth
and function size. There you would probably start with inlining from
the leaf functions not the trunk.
Haven't we gone over this before?
No good compiler does it (look at Intel's compiler, Pro64, just about
every compiler producing good code).
This is because if you know the functions with loops and loop depth,
you want to inline functions *into* them, not take random leaf
functions and try to figure out where they are called from, and whether
they are called in loops, etc.