Re: some tree-ssa vs mainline stats

[Andrew MacLeod <amacleod at redhat dot com>]

On Thu, 2003-06-19 at 10:43, law@redhat.com wrote:
> In message <1056032886.20223.27.camel@p4>, Andrew MacLeod writes:

>  >
>  >I think a secondary graph and memory location coalescing is probably
>  >most effective, and cleaner, but we'll see.  We can also only trigger it
>  >if we think we saw enough stuff during the original build to make it
>  >worth while.  I'll be doing some of this next week.
> But I don't see how this is going to reduce the number of temporaries we
> create -- it may reduce the number that are used, but if we don't look
> at gimplification closer I don't see how we can significantly cut down
> on the number of temporaries we create in the first place.
> 

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.

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? 

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

Andrew