This is the mail archive of the gcc-patches@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] Fix function body estimation


> >
> > OK,
> > stupid question how does GENERIC differ from langauge specific trees
> > when it still has language specific nodes?
> 
> The tree inliner works on GENERIC.  If a function uses language-specific
> trees for scopes, it will break.  If a function uses language-specific
> trees for some calls, they will not be inlined.  But if a function uses
> language-specific trees for some other expressions, that's OK.
> 
> The C/C++ frontends use _STMT nodes for scopes, so we need to genericize
> before inlining.  Currently we just gimplify directly.

Thanks, now I seem to understand this.
I originally got confused by thiking that C nodes are all in tree.def.
> 
> >> > Does it seem OK if I push gimplify call to cgraph_analyze_function?
> >> > Do we need to re-gimplify after inlining or is inliner already able to
> >> > keep gimple gimple?
> >> 
> >> The tree inliner can keep functions in GIMPLE form.  See all the calls
> >> to keep_function_in_gimple_form() in tree-inline.c.
> >> At one point the tree-inliner even could _only_ inline GIMPLE and keep
> >> the function gimplified, but Jason changed that.  I don't recall why.
> >
> > Jason, any idea?
> 
> As I mentioned, the inliner works on GENERIC.  The
> keep_function_in_gimple_form hack is intended to avoid duplicate
> gimplification for C/C++ by forcing the inliner to produce GIMPLE code.
> For front ends that produce GENERIC directly, it makes more sense to wait
> until after inlining to gimplify--that way the formal temporary table can
> commonize expressions between the main function and inlined functions.

What formal temporary table is?
> 
> For a while I was working on more aggressive handling of formal temps which
> would re-gimplify after inlining and replace formal temps in inlined code
> with the appropriate formal temps for the main function; currently we can
> have different formal temps for the same expression in the presence of
> inlining.  Unfortunately, this slowed things down quite a bit, and I now
> doubt it will be worth the cost in time.  It might help in some ways if we
> were to enforce the 1:1 relationship between formal temps and expressions
> and then make use of this property throughout the tree optimizers, but I
> think we already get most of the benefits from the SSA form itself.
> 
> However, if we wait until after inlining to gimplify, we get the better
> formal temp handling for free.  IMO front ends that can work this way
> (e.g. FORTRAN) should do so.

This would however results in problems in case we want to do better
analysis before we do inline decisions, such as building CFG, callgraph
and reading profile information or doing some kind of simplification to
realize where constand arguments helps optimizations to drive function
cloning.
I know nothing of this is implemented, but do you think it is good idea
to do such transformations on GIMPLE level?

Honza
> 
> Jason


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