On Mon, 2005-04-25 at 14:37, Kazu Hirata wrote: > 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
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"? 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. 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. > > 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. > Im not sure you can do it in that order without breaking DOM. > 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. 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. Andrew
