Re: [tree-ssa] Fix function body estimation

[Jason Merrill <jason at redhat dot com>]

On Sun, 19 Oct 2003 00:01:48 +0200, Jan Hubicka <hubicka@ucw.cz> 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.

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.

>> 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?

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.

Jason