[tree-ssa] live analysis on local static functions

[law@redhat.com]

In message <20031014161010.GH6212@kam.mff.cuni.cz>, Jan Hubicka writes:
 >Hi,
 >I am looking into the problems with unit-at-a-time on tree-ssa branch.
 >The testcase I am running into can be reproduced even with
 >unit-at-a-time disabled and looks like:
 >
 >static inline char * test()
 >{
 >  static char *a="";
 >  return a;
 >}
 >char * q()
 >{
 >return test();
 >}
 >
 >The dump before last DCE pass is:
 >
 >
 >;; Function q (q)
 >
 >q ()
 >{
 >  char * <Ub244>;
 >  char * retval.2;
 >  char * T.1;
 >
 >  {
 >    {
 >      static char * a = (char *)"";
 >
 >      <Ub244>_2 = a;
 >      goto <Ub1d0>;;
 >    };
 >    <Ub1d0>:;;
 >    (void)0;
 >  };
 >  (void)0;
 >  return <Ub244>_2;;
 >}
 >
 >and after dce is
 >
 >;; Function q (q)
 >
 >q ()
 >{
 >  char * <Ub244>;
 >
 >  {
 >    <Ub244> = a;
 >    <Ub1d0>:;;
 >  };
 >  return <Ub244>;;
 >}
 >
 >so we miss the initializer.  I've tracked down the problem to fact that
 >variable a does not have flag used set in it's annotation.
This doesn't sound like it has anything to do with DCE.  This sounds like
the useless statement and variable eliminator is eliminating a variable
which is actually used.

The way this works is during the translation out of SSA we mark every
variable which is used.

After we're done translating the function out of SSA form, we eliminate
variables which are not used (gimplification tends to create a ton of
variables, many of which are unused after optimization is complete).

 >I disable the inlining.  It is marked in create_ssa_var_map by seeing
 >VUSE attached to the return statement.  With inline enabled the set also
 >has VUSE but it's operand is not VAR_DECL itself, but SSA_NAME
But mark_used knows how to strip away the SSA_NAME to get at the underlying
VAR_DECL.


 >I am quite lost here.  I am not sure how the liveness should work.
It's not a question of liveness.  It's merely a question of is the variable
used or not.

I'd be very interested in seeing those dumps with the virtual operands
included -fdump-tree-all-vops.

I can make a number of speculations about what might be happening, but
the first step will be do see the dumps with the virtual operands included.

 >SHould the SSA_NAME match the expression in bind expr (as one would
 >expect for valid SSA form?)
I'm not sure what you're asking.  

 >Do we really want something like that?  (the place of BIND_EXPR in the
 >CFG is quite missleading as everything is executed before the function
 >is done just once).  What would be proper fix for that?
?!?

 >So far I can work around by disabling of removal of BIND_EXPRs for
 >static variables.  This gets me further in the bootstrap.
Which makes me even more sure something deeper is going on.

This is a static variable which is never used.  Hmmm, it's probably not
aliased (then why is it appearing in a VUSE?) and it's probably not marked
as addressable.  Right?

Can you dump the annotation for the variable as well as its tree node?


jeff