[tree-ssa] live analysis on local static functions

[law@redhat.com]

In message <1066153643.10504.2025.camel@p4>, Andrew MacLeod writes:
 >On Tue, 2003-10-14 at 13:34, law@redhat.com wrote:
 >> In message <1066151692.19104.2006.camel@p4>, Andrew MacLeod writes:
 >>  >On Tue, 2003-10-14 at 13:05, Andrew MacLeod wrote:
 >>  >> On Tue, 2003-10-14 at 13:03, law@redhat.com wrote:
 >>  >> > In message <1066149766.10504.1982.camel@p4>, Andrew MacLeod writes:
 >>  >> 
 >>  >> >  >
 >>  >> >  >I get out of ssa producing:
 >>  >> >  >
 >>  >> >  >q ()
 >>  >> >  >{
 >>  >> >  >  char * <U1244>;
 >>  >> >  >  char * retval.2;
 >>  >> >  >  char * T.1;
 >>  >> >  >
 >>  >> >  >
 >>  >> >  >  # BLOCK 0.  PRED: -1.  SUCC: 1.
 >>  >> >  >  {
 >>  >> >  >    {
 >>  >> >  >      static char * a = (char *)"";
 >>  >> >  >
 >>  >> >  >
 >>  >> >  >      #   VUSE <a_1>;
 >>  >> >  >      <U1244> = a;
 >>  >> >  >      goto <U11d0>;;
 >>  >> >  >    };
 >>  >> >  >
 >>  >> >  >    # BLOCK 1.  PRED: 0.  SUCC: 2.
 >>  >> >  >    <U11d0>:;;
 >>  >> >  >    (void)0;
 >>  >> >  >  };
 >>  >> >  >
 >>  >> >  >  # BLOCK 2.  PRED: 1.  SUCC: -2.
 >>  >> >  >  (void)0;
 >>  >> >  >  return <U1244>;;
 >>  >> >  >}
 >>  >> >  >
 >>  >> 
 >>  >> > But it still seems to me that something is missing the fact that "a"
 >>  >> > is actually used.  If "a" is marked as used, then everything ought to
 >>  >> > work as expected.
 >>  >> 
 >>  >> I am currently looking at why the VUSE <a_1> didnt mark 'a' as used.
 >>  >> 
 >>  >INterestingly, the 'a' in the BIND  has address 
 >>  >$7 = (union tree_node *) 0x400b12b8
 >>  >and the 'a' used as a base for 'a_1' is:
 >>  >$9 = (union tree_node *) 0x400adbc8
 >>  >
 >>  >so used is set on the one in $9, but never set on the one in $7.
 >> Which explains a whole lot :-)
 >> 
 >>  >Diego, any idea why we're using a different VAR_DECL?
 >> Probably an artifact of inlining I'd guess.  Does either one of them
 >> have DECL_ABSTRACT_ORIGIN set, and if so, what tree does that point to?
 >> 
 >
 >nope. both are 0. Oh wait, yeah. the one in the BIND_EXPR does ($7). It
 >points to the one we are using in a_1. (the $9 value)
Hmmm, that's kind of backwards from what I was expecting.  But I guess
it's not terribly difficult to handle.


Once my current cleanups are done testing I'll poke at this and post a patch.

jeff