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] replace keep_function_tree_in_gimple_form


> > We were using keep_function_tree_in_gimple_form for two different things,
> > which is bad.
> > 
> > Jason invented it to note whether the front end had gimplified the function
> > before inlining.  In this case, we avoid extra work by forcing our local
> 
> I would really preffer the inliner to always work on gimplified form.
> I am thinking about implementing some simple intraprocedural
> optimization using cgraph code (lets say constant propagation for start)
> and the way I would like to organize is to do
> 1) local pass:
>    in cgraph_analyze_function collect local properties of each function
>    for all global dataflow we solve
> 2) global dataflow
>    in cgraph_optimize
> 3) actual changes to tree representation
>    done in cgraph_expand_function together with expansion
> 
> This way we should be able to save program into database in between 1)
> and 2) in the case we will get into real whole program optimizer and we
> avoid need to have whole program in memory at once.
> 
> For this, however we need the functions to be gimplified and early
> optimized as part of cgrpah_analyze_function, long time before inlining
> 
> In longer term I would also like to build callgraph and profile as part
> of step 1) so we have full intraprocedural profile available.  But this
> is far away from this point.
> 
> Does this plan appear to make sense?
> If so, I think we should head to gimple-only inlining, but I am open to
> alternatives :)

One alternative is to force first pass to operate on generic, while
other can operate on gimple.
While this would work at least for simple constant propagation, it does
not appear to be right thing to do.  We probably want to do early
optimizations in cgraph_analyze_function so we know better the sizes of
function bodies and related information.
Still I am having the problem that this would force us to go into SSA
and back with current design.  How much pain would be to make inliner
operate on SSA form (this appears to be relatively easy to me - all we
need is to add phi nodes for multiple return statements, right?) and
keep around the SSA representations from as early stages as
analyze_function is?

Honza
> 
> Honza


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