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 :)

Honza


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