This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] replace keep_function_tree_in_gimple_form
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 27 Oct 2003 11:00:25 +0100
- Subject: Re: [tree-ssa] replace keep_function_tree_in_gimple_form
- References: <20031027014152.GA11370@twiddle.net>
> 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