Re: [tree-ssa] Patch ping

[law at redhat dot com]

In message <1070476514.9315.2383.camel@p4>, Andrew MacLeod writes:
 >On Wed, 2003-12-03 at 13:25, law@redhat.com wrote:
 >> In message <1070465581.9321.2268.camel@p4>, Andrew MacLeod writes:
 >>  >On Tue, 2003-12-02 at 14:06, Zdenek Dvorak wrote: 
 >>  >> Hello,
 >>  >> 
 >>  >> a few patches I spend too much time with to just let them be missed wit
 >hout
 >>  >> a word:
 >>  >> 
 >>  >> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01881.html
 >>  >>   -- a patch to save some memory by not having the unnecessary
 >>  >>      GOTO_EXPRS in branches of COND_EXPRs.
 >>  >> 
 >>  >I dont think I like this patch because it gives us a dual mode
 >>  >COND_EXPRs. Sometimes its code and sometimes its just a label, which
 >>  >makes the GOTO_EXPR code implicit instead of explicit. With this change,
 >>  >the meaning of a COND_EXPR is not compatible with the definition in
 >>  >GENERIC/GIMPLE. With things like mudflap running after tree-ssa, this is
 >>  >going to impact them as well.
 >>  >
 >>  >You are right, it is a waste of memory, and its meaning could be
 >>  >changed. Its what, about 48 bytes extra per COND_EXPR node? I dont think
 >>  >the memory is significant enough personally, but others may differ :-)  
 >> If we're going to go this way, then I'd want to push this concept to all
 >> uses of COND_EXPR.  Either the ARMs are statements or they are not.  Having
 >> them be statements in one context and raw labels in others is a bad design
 >> and a long term recipe for disaster. 
 >
 >I dont think we can make it always a label, or the "containerness" is
 >lost to the front end, which is where they really want it.
Right.  That's the fundamental problem.  I really don't want to see 
the arms of a COND_EXPR have different meanings at different times.  That's
bad.

 > The only real
 >way to do this is to have another TREE_CODE, and I dont like that idea.
I'm not sure how much I like/dislike this.  The only way this wins is if
the old COND_EXPR node goes away completely, which it probably would.  
Then it becomes a question of whether or not the memory savings of our
new node is enough to overcome the increased memory fragmentation and
loss in locality (assuming we had any locality to begin with! :(


IMHO There's more attractive memory improvements to be made elsewhere.
For example SSA_NAMEs are still a huge component in our memory consumption
within the SSA path.

We could improve SSA_NAME recovery if bsi_remove released them, but I'm
not sure I want bsi_remove to know about this kind of stuff.  Plus bsi_remove
is used by code which wants to move a statement to a different location.
Thoughts?

Jeff