This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Multiple simplification calls


On Fri, 21 Feb 2003 09:49:24 -0700, law at redhat dot com wrote:

> So my goal for today was to at least better understand why gimplification
> was so bloody slow (it accounts for over 2% of our compilation time right
> now).
>
> The first thing I noticed was that every function is gimplified twice,
> yup, twice.
>
> The first simplification happens when finish_function calls c_genericize,
> which in turn calls simplify_function_tree.

Yep.  For a while I was trying to do genericization without simplification,
but the existence of statement-expressions means that we'd still have to
walk the whole function.

> The second happens a short while later when finish_function calls
> c_expand_body which later calls simplify_function_tree.
>
> Presumably we do this because something in between those two calls to
> simplify_function_tree may create non-gimple code?  If that's the case,
> is there any way we can avoid creating non-gimple code or at least
> keep track of the introduction of non-gimple code?

The something is the inliner.  But since the functions being inlined are
already simplified, the only non-gimple thing about the inlined code is
using the BIND_EXPR directly in a containing expression; simplification
moves it to the prequeue and replaces it with a temp.  It would be possible
for the inliner's tree walker to keep track of the containing statement and
do an equivalent transformation.  I'm not sure whether or not we need to
worry about parameter substitution creating non-gimple code, in the manner
of CCP.

The main obstacle is that the interface between the frontend and tree
backend should be generic, not gimple; it's simpler to do inlining on
generic, and there may be other (perhaps language-specific) optimization
passes for which that is also true.  I also don't want to require frontends
to produce gimple code.  I'd prefer to fix this duplication of effort by
moving the C and C++ frontends to generating generic internally.

A possible quick hack to speed up -O0 compiles would be to set a flag in
c_genericize and use it to skip the second simplification pass if we
haven't done inlining.

> To give you some idea, right now simplification directly accounts for about
> 2.2% of our total compilation time for my tests (15.26 seconds).  Avoiding
> the second call gets that down to about 1.2% (8.38 seconds).  As a secondary
> effect the garbage collector has less work to do and we save another half
> second there.

Hmm.  We shouldn't be allocating new copies of things on the second pass;
it should just walk the tree and verify that it's gimple.  Fixing that
will probably improve things.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]