Hi Andrew,

> well, there isnt a tree_statement_list_node right... DOM simply has an
> expression, and we end up calling create_stmt_ann.  I guess you would
> have to create a completely detached stmt_list node for this case.  what
> are you planning to have create_stmt_ann do? 

I am thinking about leaving create_stmt_ann as is just for
create_ssa_artficial_load_stmt.  Other than that, I don't want to call
create_stmt_ann.  I am planning to allocate stmt_ann as a part of
tree_statement_list_node.  That is, if I have this

struct tree_statement_list_node
  GTY ((chain_next ("%h.next"), chain_prev ("%h.prev")))
{
  struct tree_statement_list_node *prev;
  struct tree_statement_list_node *next;
  tree stmt;
  struct stmt_ann_d ann;
};

then tsi_link_after and tsi_link_before would allocate the right
amount of memory because they have

  head = ggc_alloc (sizeof (*head));

where head is a a pointer to tree_statement_list_node.  I still have
to initialize members of stmt_ann_d.  I believe all I have to do is

  memset (ann, 0, sizeof (ann));
  ann.common.type = STMT_ANN;
  ann.modified = true;

> I eventually want to see this entire routine go away. The only reason
> DOM wants it is so that it can scan the operands like it does for a real
> stmt. noone else needs to do such a thing.. Presumably the overhead of
> actually inserting these loads immediately after the store and deleting
> them later is too high...   Ive never looked at the details of what DOM
> does with the info.  if it only needs the operands for a short time, a
> different interface could be provided which returns the operands in a 
> VEC or something. I just never felt like looking at DOM too heavily.

I guess we can come back to this once stmt_ann is merged into
tree_statement_list_node.  I don't feel like mixing infrastructure
work and optimizer work.

By the way, I just realized you were planning to do "New SSA Operand
Cache Implementation" in stage 2, which is starting tomorrow.  Would I
be stepping on your toes?  I am not planning to change the members of
stmt_ann, so hopefully my work won't interfere with yours, but if it
does, please let me know.

Kazu Hirata

Reply via email to