[tree-ssa] live analysis on local static functions

[Jan Hubicka]

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

OK, thanks!
BTW with the patch to avoid removal and -funit-at-a-time on by default,
I can get into stage3 but then I get abort in finish_spills :(

Honza
> 
> jeff
>