This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Fix function body estimation
> On Sun, 19 Oct 2003 00:01:48 +0200, Jan Hubicka <firstname.lastname@example.org> wrote:
> >> 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?
> A formal temporary table is a data structure in a compiler which provides a
> 1:1 map between expressions and temporaries, so that when an expression is
> evaluated, its value is always stored in the same temporary.
I see, this is the idea from Morgan's book.
I was thinking about this and GCC and seems to me that at least from RTL
backend doing so would be disasterous. It generally deal badly with
unnecesary register reuses. In the case tree-ssa does this and the
temporaries remain unified up to the RTL level, it would be interesting
to see how webizer is effective when run very early in the RTL backend.
> The implementation in tree-ssa is not as formal as the one described in
> Morgan's book; he describes special handling of expression temporaries in
> many different places, whereas we just treat them like any other register
> variable. For instance, his formal temps are invalidated when one of their
> operands changes. But most of these have only seem to improve handling of
> normal form; there seems to be no compelling reason to do otherwise since
> we are only doing interesting work in SSA form.
How this improve the SSA conversion? It seem to me that the SSA
optimizers should be pretty much independent of sharing temporaries. I
recall that MOrgan's book uses the trick extensivly for global
optimizers but these are mostly non-SSA ones.
> If we are going to make inlining decisions based on flow analysis, we would
> certainly want to defer inlining until after we can do that analysis; that
> would change the trade-offs involved.
Yes, I would like to use flow analysis for inlining. Profile feedback
is obivously usefull at that level and there is followup on Ball's &
Larus paper claiming that static profile estimates do identify hot spots
of program with good probabilities.
Thre is long way to go, but I would like to proceed this direction.