Re: some tree-ssa vs mainline stats

[law at redhat dot com]

In message <200306182344.h5INi34X020009@gremlin.ics.uci.edu>, Dan Nicolaescu wr
ites:
 >Observations:
 > - tree-ssa is allocating a lot more memory 
Yes.  We haven't got to a point yet where we're looking closely at 
memory allocation.  Right now the focus is on compile-time performance
issues -- primarily ones resulting from poor algorithms, silly 
implementation details or passing too much crud to the backend.

We know we're going to have to spend a considerable amount of time on
the memory issues as well.

 > - the overheads are a higher for tree-ssa, so it seems that it needs
 >   a few extra values added to ggc-page.c:extra_order_size_table
Yes.  For example, tree_common has 2 extra pointers (one for an annotation
the other for locus information).


 >Total # of identifiers:
 >generate-3.4.ii SSA  84136 
 >generate-3.4.ii HEAD  8131 
 >combine.i       SSA  10987 
 >combine.i       HEAD  4389
 >
 >
 >Does tree-ssa create unique identifiers for each ssa name, or
 >something similar? Is that OK?
We have to create a number of new identifiers to hold temporaries during
the gimplification process.  For example if you had a tree node like

x = a + b + c + d;

We turn that into something like

  t1 = a + b;
  t2 = t1 + c;
  x = t2 + d;

Flattening of the trees by its nature is going to create more temps.  As
is getting proper EH semantics.


 >Total number # of insns in .00.rtl 
 >generate-3.4.ii SSA   417674
 >generate-3.4.ii HEAD  728202
 >combine.i       SSA    41528
 >combine.i       HEAD   35524
I don't know if the reduction in insns for generate.ii is due to tree-ssa
optimizing better or doing something like not inlining as well.  I tend to
suspect the latter as most of the time it tends to produce more insns
than without tree-ssa.

Jeff