[tuples] meaning of DECL_SAVED_TREE while analyzing cgraph

[tuples] meaning of DECL_SAVED_TREE while analyzing cgraph

[Aldy Hernandez]

Hi Jan.

What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:

      /* ??? It is possible to create extern inline function and later using
	 weak alias attribute to kill its body. See
	 gcc.c-torture/compile/20011119-1.c  */
      if (!DECL_SAVED_TREE (decl))
	{
	  cgraph_reset_node (node);
	  continue;
	}

      gcc_assert (!node->analyzed && node->reachable);
      gcc_assert (DECL_SAVED_TREE (decl));

It was my understanding that DECL_SAVED_TREE was to be cleared after the
tree optimizers executed, and Diego is explicitly killing it now right
after gimplification-- at the end of gimplify_function_tree:

    /* The tree body of the function is no longer needed, replace it
       with the new GIMPLE body.  */
    set_gimple_body (fndecl, seq);
    DECL_SAVED_TREE (fndecl) = NULL_TREE;


I also thought that after the CFG was built, DECL_SAVED_TREE had nothing
of value left.

So, what do you expect it to have?  Can we use something in the tuple
body now, or do you are you overloading DECL_SAVED_TREE for somthing
else?  Also, the assertion of DECL_SAVED_TREE above is unecessary, since
you've already checked for a lack of it, and looped.

Please let me know.

Thanks.
Aldy

Re: [tuples] meaning of DECL_SAVED_TREE while analyzing cgraph

[Jan Hubicka]

> Hi Jan.
> 
> What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:
> 
>       /* ??? It is possible to create extern inline function and later using
> 	 weak alias attribute to kill its body. See
> 	 gcc.c-torture/compile/20011119-1.c  */
>       if (!DECL_SAVED_TREE (decl))
> 	{
> 	  cgraph_reset_node (node);
> 	  continue;
> 	}
> 
>       gcc_assert (!node->analyzed && node->reachable);
>       gcc_assert (DECL_SAVED_TREE (decl));
> 
> It was my understanding that DECL_SAVED_TREE was to be cleared after the
> tree optimizers executed, and Diego is explicitly killing it now right
> after gimplification-- at the end of gimplify_function_tree:
> 
>     /* The tree body of the function is no longer needed, replace it
>        with the new GIMPLE body.  */
>     set_gimple_body (fndecl, seq);
>     DECL_SAVED_TREE (fndecl) = NULL_TREE;
> 
> 
> I also thought that after the CFG was built, DECL_SAVED_TREE had nothing
> of value left.
> 
> So, what do you expect it to have?  Can we use something in the tuple

Well, take a look at the testcase mentioned in comment - it is a bit
weird side case where frotend produces function with body, passes it to
cgraph and then take the body back before end of compilation unit.

The test there is sort of hack, I would just remove it at this stage and
we can work out better fix for that testcase later.  I hope that with my
plans for declaration merging pass we can get round such weird side
effects of in place declaration replacement.

Honza
> body now, or do you are you overloading DECL_SAVED_TREE for somthing
> else?  Also, the assertion of DECL_SAVED_TREE above is unecessary, since
> you've already checked for a lack of it, and looped.
> 
> Please let me know.
> 
> Thanks.
> Aldy

Re: [tuples] meaning of DECL_SAVED_TREE while analyzing cgraph

[Aldy Hernandez]

> The test there is sort of hack, I would just remove it at this stage and
> we can work out better fix for that testcase later.  I hope that with my
> plans for declaration merging pass we can get round such weird side
> effects of in place declaration replacement.

Will do.

How about all the other uses of DECL_SAVED_TREE in cgraph_analyze_functions?
DECL_SAVED_TREE shouldn't be used past the tree optimizers (??).

Aldy

Re: [tuples] meaning of DECL_SAVED_TREE while analyzing cgraph

[Jan Hubicka]

> > The test there is sort of hack, I would just remove it at this stage and
> > we can work out better fix for that testcase later.  I hope that with my
> > plans for declaration merging pass we can get round such weird side
> > effects of in place declaration replacement.
> 
> Will do.
> 
> How about all the other uses of DECL_SAVED_TREE in cgraph_analyze_functions?
> DECL_SAVED_TREE shouldn't be used past the tree optimizers (??).

There are also few other occurences in cgraph.c and ipa-inline.  Those
are used to test whether function body is present.  When you have body
elsewhere now, you can check something else (such as
DECL_STRUCT_FUNCTION(cfun)->cfg)

We can probably move those changes to mainline to avoid pointers
dangling around, I can try to look into this.

Honza
> 
> Aldy

Re: [tuples] meaning of DECL_SAVED_TREE while analyzing cgraph

[Diego Novillo]

On 7/31/07 6:10 PM, Jan Hubicka wrote:

> There are also few other occurences in cgraph.c and ipa-inline.  Those
> are used to test whether function body is present.  When you have body
> elsewhere now, you can check something else (such as
> DECL_STRUCT_FUNCTION(cfun)->cfg)

Currently, in tuples, the presence of the GIMPLE function body is given
by gimple_body(fndecl).  After the CFG has been built, then
D_S_F(cfun)->cfg will be non-NULL.

We should abstract these two tests into a single predicate.  Also,
testing for the CFG of a function should be something like cfg (fndecl)
or something along those lines.