Re: some tree-ssa vs mainline stats

[law at redhat dot com]

In message <1056032886.20223.27.camel@p4>, Andrew MacLeod writes:
 >>   1. Combining totally unrelated variables.  I'm not sure if this is wise
 >>   or not.
 >> 
 >
 >I was planning this for any T.* variable that are of the same type. We
 >generate a *lot* of these, and most of them are live for very short
 >periods. THey are clear wins.
Makes sense.

 >
 >>   2. Elimination of unused variables.  Thus allowing their nodes to be
 >>   released.   This mostly speeds up expansion by having fewer variables
 >>   to expand.  It can also save stack space (imagine an addressable
 >>   VAR_DECL which is unused).
 >> 
 >I thought your cruft cleanup did that? Perhaps I am mistaken...
It will -- once I get back to fixing our issues with nested functions so
I can enable that code :-)  The top of my stack is the EH CFG cleanups :-)


 >> Neither of these attacks the "problem" at the source, namely gimplification
 >> really likes to create new variables.  I don't offhand know how wasteful
 >> the gimplifier is being these days.  The one area I know the gimplifier 
 >> sucks and creates unnecessary temps is NOP conversions.
 >> 
 >
 >I see lots of local automatics on big function. Lots. There is
 >definately a footprint to be reduced.
 >
 >THe main part of the experiment was really the location of the pass...
 >Do I include this as part of the original conflict graph and coalescing,
 >or do I do some of it as a seperate run later.. Im not sure which is
 >faster. The original conflict graph will be a lot denser, and it has a
 >lot more elements in it. THe secondary one after the initial coalescing
 >would be a lot smaller...
 >
 >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.

jeff