Re: [tree-ssa] Multiple simplification calls

[law at redhat dot com]

In message <wvl8yw9utn3 dot fsf at prospero dot boston dot redhat dot com>, Jason Merrill writes:
 >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.
Right.  But presumably once we're finished with c_genericize we're also
in gimple form, correct?



 >> 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.
OK.  The key thing I was missing was the BIND_EXPR -- it seemed to me that
if the inlined code was in gimple form that substitution into the 
caller would keep things in gimple form.  Now I know why it doesn't.

So presumably we could avoid the second gimplification process if we 
revamped how the inlined function was substituted into its caller.
How hard would that likely be?

I'm guessing parameter substitution should be OK -- at least at first
glance.  From a C standpoint they're just gimple MODIFY_EXPRs.  I don't
know enough about the C++ bits to know if they would be more complicated.


 >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.
Probably a reasonable long term solution. 

 >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.
I'm not trying to speed up -O0 :-)  I'm trying to speed up -O2.  gimplification
takes 2% of our -O2 compilation time.  I didn't measure what percentage it
takes for -O0.


If it's not terrible I'd prefer to fix the inliner so that we didn't need
the second simplification pass.

 >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.
Probably so, but you still have to look at all those *(@&$ tree nodes.

Another possibility might be to mark those BIND_EXPRs and their parent
blocks.  Then in the second simplification pass we only traverse down
into blocks which were marked.  Dunno if that's feasible or not.

I'll probably be at a point where I'll be ready to poke at this early next
week, so any additional insight/thoughts would be greatly appreciated.

jeff