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

[Joe Buck <jbuck at synopsys dot com>]

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.

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

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