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

[Jim Wilson <wilson at specifixinc dot com>]

Gabriel Dos Reis wrote:
> 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.
>
> 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 canonical example is C++ references, which were impossible to handle 
efficiently in the RTL inliner, but are handled very well by the tree 
inliner.

The RTL level is just too low of a level, with too many hardware details 
exposed, for good function inlining.  We did it there long ago because 
we had no choice.  Now that we have a better way to do it, we can get 
rid of the RTL inliner.

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

I don't agree with this.  We haven't been doing (2).  There is no 
architecture dependent knowledge in the RTL inliner.  All it does is the 
exact same work as the tree inliner, except that it is much harder to 
get it right because it is working on a low level machine dependent IL.

It does make sense to perform some optimization as both high and low 
levels.  Cse for instance is still useful at RTL, because some common 
subexpressions will be exposed by lowering.

However, the same is not true for calls.  The only calls that get 
exposed by lowering to RTL are libcalls, and the RTL inliner has no 
support for them.  If we did want to support inlining of libcalls, we 
could do it with code a lot simpler than the current RTL inliner.

I don't have the details handy, but I believe that there are known 
problems that can result when both the tree inliner and the RTL inliner 
are used, which is another reason why people want to get rid of the RTL 
inliner.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com