Re: [tree-ssa] Patch ping

[Andrew MacLeod <amacleod at redhat dot com>]

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 without
>  >> 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. The only real
way to do this is to have another TREE_CODE, and I dont like that idea.

> 
> There's far more effective means of reducing our memory consumption than
> something like this right now.
> 
>  >It was also mentioned briefly in
>  >http://gcc.gnu.org/ml/gcc-patches/2003-10/msg02235.html
>  >and we were suppose to implement the accessor macros to hide the
>  >GOTO_EXPRs and go directly to the labels, which I think we forgot to do
>  >and ought to be done. 
> Agreed.
> 
Zdeneks patch does most of the legwork needed to do this, it just needs
to get rid of the actual GOTO_EXPR replacement and use new macros
instead of COND_EXPR_THEN/ELSE to access the labels.

Andrew