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

I fully understand and appreciate the cases where the tree-inliner
could do a fairly better job that the RTL-inliner.  That is not the
point.  What I was asking for are the reasons why people make the
assertion that the tree-inliner should replace the RTL-inliner,
meaning that it does a better job in all cases and provides better.

| 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

My point is precisely that since the RTL-inliner has so much finer
grained details of the hardware, it is better suited for integration,
i.e. inlining at low level -- and in effect old good RTL-inliner does
do good job in some cases where the tree-inliner performs poorly. 

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

Complaints about inlining regressions from 2.95.x to 3.x are evidence
that  the RTL-inliner is not doing the same as the tree-inliner.

And if RTL has hardware details (which everyone agrees one), then I
see no reason not to use them.  Our having a tree-inliner is no
sufficient reason not to have the RTL-inliner makes a better
complementn job.  

[...]

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

I would really appreciate to see those problems.

-- Gaby