Re: Beginner's question:Are there any inter-procedural optimization in GCC backend ?

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Jim Wilson <wilson@specifixinc.com> writes:

| Gabriel Dos Reis wrote:
| > Hmm, it has been my understanding thta the tree-inliner will not
| > (automatically) have us throw away the RTL-inliner.  Does that change?
| 
| The tree inliner should always do a better job (except for problems
| with heuristics of when to inline), so I don't see any good reason to
| keep the RTL inliner.

I've seen that claim made as a postulate several times; however, I've
not seen any convincing explanation of why that should be the case. 

| However, we do have the problem that not all front ends support tree
| inlining yet, so for now, we still need the RTL inliner.  I expect
| this changes with the tree-ssa branch, since there all front ends have
| to generate gimple, and hence all front ends get the benefit of tree
| inlining.
| 
| Is there some other reason why we would want to keep it?  It seems
| like a bad idea to have two function inliners making different
| decisions about what to inline.

I would not say that is a bad idea.  I believe there is at least two
"inlining":
  (1) a high level inlining (presumably tree-based) that exploits
      language-specific semantics
  (2) a low-level inlining (presumably RTL-based) that happens after
      lowering and that exploits architecture-dependent knowledge.
      I think "integration" is probably a better name.

Previously, we've been doing only (2).  Now, we seem to be favouring
only (1), with all implied problems.  I don't think one size fits all
in this specific area.

-- Gaby