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

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

Joe Buck <jbuck@synopsys.com> writes:

| Jim Wilson <wilson@specifixinc.com> writes:
| > | 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.
| 
| On Thu, Nov 06, 2003 at 04:14:10AM +0100, Gabriel Dos Reis wrote:
| > 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. 
| 
| The main issue with the RTL inliner is that, by the time it is invoked,
| decisions have been made that are very difficult to undo (e.g. lay out
| structs on the stack).
| 
| > | 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
| 
| But we're planning to turn all languages into GIMPLE, right?  Inlining
| on GIMPLE trees is language independent.

GIMPLE is supposed to be a higher level IR; in particular, as I
understand various plans going on, we should not commit to RTL
generation (and there using hardware details like number of available
hard registers) only when necessary.

| >   (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.
| 
| Architecture-specific information (for crude cost estimates) can be made
| available at tree level.

I'm not sure they would be as useful as at lower IL.

| > 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.
| 
| Clearly before we kill (2) we'd have to be at the stage where (1) alone
| can do a good job.  At this stage, the tree-based inliner still falls
| way short and we do no better on temporary multi-field struct arguments
| than we used to, so we still need improvements before we are production
| ready.

agreed.

-- Gaby