Re: [PATCH]: Add annotations for expression and constants

[Daniel Berlin <dberlin@dberlin.org>]

On Jun 10, 2004, at 9:24 AM, Diego Novillo wrote:

> On Sun, 2004-06-06 at 12:46, Daniel Berlin wrote:
>
>> 	* tree-flow.h (tree_ann_type): Add CST_ANN, EXPR_ANN.
>> 	(struct cst_ann_d): New.
>> 	(struct expr_ann_d): New.
>> 	(union tree_ann_d): Add cst_ann, expr_ann.
>> 	* tree-dfa.c (create_cst_ann): New function.
>> 	(create_expr_ann): Ditto.
>> 	* tree-flow-inline.h (cst_ann): New function.
>> 	(expr_ann): Ditto.
>> 	(get_cst_ann): Ditto.
>> 	(get_expr_ann): Ditto..
>>
> The annotations are empty.

For now ;)

>  What are you going to store in there?
A single value.
It's right now a tree, but will probably move to a hash value 
eventually. We use fake VAR_DECLs for the value right now so that they 
print out nicely, are easy to track, etc, but they are a bit memory 
intensive for this purpose so eventually we'll move away from this, i 
reckon.

> Just
> a single hash value?
yes.

> Perhaps we could make this faster and hijack tree_common.ann to store 
> them directly there.


I'd have to create a new union or void *ify it, since it's currently a 
union tree_ann_d *, not a void *.   But i can't easily void * it 
because it's GC'd.

(IE
struct tree_common GTY(())
{
   tree chain;
   tree type;
   union tree_ann_d *ann;
)

In order to support GC on it, I'm pretty sure i have to create a union, 
but the value number members would be marked deletable/skip, since we 
don't need them after a ggc_collect.  Either that, or i'd have to keep 
a list of expressions and CST's we hijacked, and re-null them at the 
end of the pass so it doesn't screw up GC.
Just thinking about this is starting to make my head hurt :(

>  After all, the hash
> values will end up in a field of SSA_NAME nodes, right?
yes.
When you deleted the ssa_name_ann yesterday, i moved it to the tree 
structure for SSA_NAME's.

>
> If that's the case, perhaps we would be better off just overloading
> tree_common.ann while GVN-PRE runs and then move that value into the
> corresponding SSA_NAME.  If there's more state that you want to keep,
> let's use this approach.
>

Nope, no more state.

>
> Diego.
>