Re: [tree-ssa, RFC] SSA_NAMES and overload of chain field

[Jan Hubicka <jh at suse dot cz>]

> In message <20031128224306.GO1906@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >Hi,
>  >the chain filed is special because GGC is aware of fact that the chain
>  >is used as linked list:
>  >union lang_tree_node
>  >  GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"),
>  >       chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE ? (union lang_tre
>  >e_node *)TYPE_NEXT_VARIANT (&%h.generic) : (union lang_tree_node *)TREE_CHAIN
>  > (&%h.generic)")))
>  >
>  >The use of the field in SSA_NAME_DEF_STMT breaks this expectation and
>  >confuses GGC when multiple SSA_NAMES point to same DEF_STMT.
>  >
>  >The attached patch fixes it by avoiding the overload of chain and ading
>  >separate field for this, but I am open for further suggestions.
>  >
>  >Bootstrapped/regtested i686-pc-gnu-linux in isolation
>  >and additionally x86_64-linux in combination with two patches sent
>  >earlier.
>  >Honza
>  >
>  >2003-11-28  Jan Hubicka  <jh@suse.cz>
>  >	* tree.h (SSA_NAME_DEF_STMT): Use def_stmt field.
>  >	(tree_ssa_name): def_stmt.
> Use the annotation field or something like that.   Otherwise you end up
> throwing SSA_NAMEs into a different GC pagesize.
> 
> However, before doing that, I'd like a clearer explanatation of why using
> the TREE_CHAIN field is causing problems.

The explanation comes in later email.  The algorithm used by GGC didn't
work right in the case chain ended up by pointer pointing to last node
(in that case nothing pointed to by last node get marked and we
eventually run into accessing freed memory).
I've sent patch to fix this too, so I guess we can keep current overload
of SSA_NAMEs.

Honza
> 
> Jeff
> 
>