This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Some optimization thoughts (and thanks!)
- To: Joern Rennecke <amylaar at redhat dot com>
- Subject: Re: Some optimization thoughts (and thanks!)
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: 05 Jun 2001 17:38:12 -0400
- Cc: carlo at alinoe dot com (Carlo Wood), At150bogomips at aol dot com,gcc at gcc dot gnu dot org
- References: <200106052125.f55LPY223386@phal.cambridge.redhat.com>
Joern Rennecke <amylaar@redhat.com> writes:
>> The compiler can't know how often a function is called, only the linker
>> can. This would be possible for static functions, but I'd be highly
>> surpriced when static functions with one caller aren't already inlined :/
>
> They are only inlined if they precede the caller, and are below the
> inlining threshold. Most functions (those above the inlining threshold)
> are immediately after optimization, before gcc tackels the next one,
> so gcc doesn't know if a function is called just once when it has to
> make the decision if to inline or not.
>
> But even if it knew, it would not be desirable to indiscriminately inline
> functions, not with the way the register allocator works right now.
> For a large inlined function, the caller with inlined callee tends to
> be larger and slower than the caller with out-of-line callee together.
> This is because the register allocator is rather clumsy when faced with
> a large overall demand of registers in a large function.
> Two optimization techniques - live range splitting and shrink wrapping -
> promise to overcome these problems, but they create variable /
> register/memory assignments that are hard or impossible to describe with
> some (most?) debugging information formats.
Errr, depends on your context of "some" and "most".
If you mean by sheer number of debug formats, you are correct to say
most.
If you mean by what people use, you have to realize that a large
majority of compilers these days use DWARF2 , which can describe it
just fine, and in fact, it's not even difficult to do. I'd classify it
as quite trivial, in fact, having done it for the graph coloring
register allocator (which does some live range splitting automatically).
I'd guess by the time all the various issues around the new allocator are
resolved, we could just turn off the new allocator for non-dwarf2
targets, and be done with it.
--
"The other day, I was walking my dog around my building... on
the ledge. Some people are afraid of heights. Not me, I'm
afraid of widths.
"-Steven Wright