Re: some tree-ssa vs mainline stats

[law at redhat dot com]

In message <1056036088.20227.37.camel@p4>, Andrew MacLeod writes:
 >Ah, well, I guess it wont change the number we create... Im interested
 >in the number we use :-)  If we reduce the number we use, that space can
 >be reclaimed and reduce the overall footprint, but not as much as
 >reducing the number we create.
Right.  Reclaiming the memory is good.  Smaller conflict structures to
deal with in coalescing, etc etc are all good things.


 >We really only need one temporary of any given type once we hit SSA...
 >and SSA_NAME versions for every instance...  The gimplifier is earlier
 >than that tho. hmm.
 >
 >I don't suppose that the gimplifier knows when its done with a
 >temporary?  They aren't live past a stmt boundry are they? 
It doesn't know.  I don't think an are life past the original
statement boundary when we're done with gimplifying.  However
be aware that we have a formal temporary table now and try
to ensure that every time we evaluate a pure expression the
destination is the same formal temporary.

 >If it did know, instead of creating a new temporary every time one is
 >needed, it could grab an existing one of the same type, if it is
 >available. If there isnt a free one, then a new one would be created.
 >When its done with a temporary (or all of them for a stmt), it could
 >release it/them back in the available pool. That oughta save a lot...
 >
 >
 >In fact, it would pretty much perform the coalescing I was going to do
 >with T.* variables...
Interesting idea.  The coalescing I was thinking about for T.* variables
was just to coalesce them with related user variable driven by seeing
a T. and a user variable in a PHI or copy.

Jeff