bug introduced by inlining patch

[Kurt Garloff]

Hi Daniel,

On Wed, Sep 04, 2002 at 02:35:44PM -0400, Daniel Berlin wrote:
> > 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.

Quite strong statement.

> Haven't we gone over this before?

Yes. Well, apparently neither of us succeeded in convincing the other.
Basically your argument is ...

> No good compiler does it (look at Intel's compiler, Pro64, just about 
> every compiler producing good code).

... which I do not consider very convincing, whereas mine is that you'll
have more calls to leaves than somewhere else in the call tree.
(You can construct cases where this is not the case of course, as there
 are conditionals, but in average it will be true.)

> 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.

But if you gather the complete information of your call tree, your 
inlining decisions will be independent from where you start with it,
so this discussion is a noop. Rather an implementation detail.

Basically, you will know for every function in your call tree what
1size is and what the loop depth level is (and ideally have some estimate 
for the iteration counts, in terms of small vs medium vs large).
You'll use some algorithm to take the ideal decisions and it should
not matter at what functions it looks first.

In presence of very incomplete information, I'd still bet that starting
from the leaves is better.

PS: I would love to have enough time to work on this.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20020904/d245c515/attachment.sig>