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
