Re: [tuples] meaning of DECL_SAVED_TREE while analyzing cgraph

[Jan Hubicka <jh at suse dot cz>]

> 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