Re: Rename tree_ann to tree_ann_t

[Diego Novillo <dnovillo at redhat dot com>]

On Mon, 2004-05-17 at 16:35, Steven Bosscher wrote:
> On Monday 17 May 2004 22:20, Diego Novillo wrote:
> > On Sun, 2004-05-16 at 06:32, Steven Bosscher wrote:
> > > But the generic tree_ann is a type name, where the other kinds
> > > of tree annotations have a *_t suffix.  This patch renames
> > > tree_ann to tree_ann_t, and adds a few functions to create and
> > > access the generic tree_ann_t annotations.
> >
> > Why do you want to create a generic tree_ann_t object?  What annotations
> > are you trying to add?  It'd be better to sub-type them like we did for
> > the others.
> 
> We attach them to expressions (in this context, anything that can 
> be the rhs of a MODIFY_EXPR) to get the value representative for
> that expression without looking it up in a hash table.
> 
Let's create expr_ann_t then.  I hope you are not trying to attach one
of these on the RHS of 'a = b', eh?

In terms of the general problem of annotations, I'd like to hear
opinions from Nathan and Zack.  They are working on statically typed
trees and they may have thoughts on this.  Zack, Nathan, we use
annotations to store bits of information useful only when optimizing. 
The general rule of thumb is to use annotations when the overhead of
hash or other on-the-side data structures is too high.

I would like to have a generic mechanism for this.  We have an
annotation scheme that sort of works but it's dynamically checked (See
var_ann_d, stmt_ann_d, ssa_name_ann_d in tree-flow.h).  Do you have any
thoughts about this?


Thanks.  Diego.