This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]