Re: bug introduced by inlining patch

[Daniel Berlin <dberlin at dberlin dot org>]

>  Next improvement would be to calculate the complete call graph
>  and then
>  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.
Once again, there is never a good reason to inline starting at the 
leaves when you have good information like loop depth, estimated call 
counts, etc.
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.
--Dan