This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beginner's question:Are there any inter-procedural optimizationin GCC backend ?
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> 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.
The complaints are of the form "I expected X to be inlined into Y and
it wasn't." The complaints mostly do not provide hard numbers which
demonstrate that this caused a measurable performance regression.
(Some have; I don't dispute that the tree inliner needs improvement.)
I want to see profiling numbers, collected in a wide variety of
scenarios, before I will believe that "failure to inline" is a
genuine problem of wide impact.
> 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.
Could you give examples of cases where you think inlining could do a
better job with access to hardware details?
> | 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.
Two are known to me:
1) PR 9972 has been concluded to be impossible to fix so long as some
front ends use both inliners.
2) The RTL inliner is a major obstacle to making all RTL be
transiently allocated, and therefore to removing RTL from the
purview of the garbage collector. Daniel Berlin has numbers
indicating that allocation of RTL from the GC heap causes huge
amounts of memory to be wasted, with consequent compile-time
performance hit.
zw