Hi Andrew,
> How is the get_stmt_ann (stmt) going to work from the caller of
> create_ssa_artificial_load_stmt() when it goes to look at the operands
> for its new "stmt"?
I am going to replace that particular call to get_stmt_ann with a call
to create_stmt_ann. The beginning of create_ssa_artficial_load_stmt
would look like
/* Make sure we don't have a stmt_ann already. */
gcc_assert (stmt_ann (stmt) == NULL);
/* Create a standalone stmt_ann that is not a part of
tree_statement_list_node. */
create_stmt_ann (stmt);
> The annotation was simply attached to the stmt before, so it was
> easy to locate. There is no bsi_for_stmt() since it isnt a real
> stmt, so you can't get to a stmt_list node that way either. Im not
> sure how you would locate the annoation for a fake stmt like this.
I am going to keep stmt_ann() so that you can get to stmt_ann from
stmt even for a fake statement.
Eventually, we might want to replace stmt_ann() with
stmt_ann_from_bsi() so that you can get to stmt_ann from bsi directly
without going through a statement proper. I think this is a good
follow-up project and should be a good preparation for Zdenek's flat
statement tree project.
> And DOM treats it like a real stmt by calling the same routines, so I
> dont know how you could change this without first making DOM do
> something different.
Again, I'll let DOM create its own instance of stmt_ann_d for stores.
Since it's only used for look-ups and never entered into the
instruction stream, I don't think that would cause a problem.
> I have the patch done, I'm evaluating whether its worth using or not.
>
> I doubt you would be stepping on my toes any more than the annoyance of
> diffs not applying all over the place like they did with
> get_stmt_operands() being removed.
OK. Meanwhile I'll sit here quietly, collecting information like
which places do weird things with stmt_ann and thinking about how to
go about the transition.
Kazu Hirata
