------- Additional Comments From amacleod at redhat dot com 2005-09-19 16:33 ------- Its not the same thing since we arent actually releasing an SSA_NAME until between passes. All we are doing is clearing the SSA_NAME_DEF_STMT field. True that inserting a stmt after bsi_remove will not set the SSA_NAME_DEF_STMT field back, but we could set it during the bsi_insert and bsi_replace routines. The operand scanner now sets all the defs, so its just a matter of loping over the defs and setting the field.
I don't understand the last bit of your comment: "And that will not work for the SSA_NAMEs used for aliasing and then the variable becomes a gimple register." If we set SSA_NAME_DEF_FOR_STMT during inserts, and clear it during bsi_remove, does that resolve the issues you are referring to? Im simply trying to have a maintenance free mechanism for handling releasing ssa_names that doesn't involve having to find all the locations where they are free and calling a routine to free them. That is undesirable. We originally wanted to be able to just free them, but ran into some issues that couldn't be resolved at the time. I believe those problems can now be resolved. We had lazy updating of statements back then as well which made doing this fix during inserts impossible. That restriction is no longer present either. (except in DOM... it has a hacked up loop to allow lazy updating until it is fixed. I dont know if there is an issue there or not. The DOM fixup loop might also have to set SSA_NAME_DEF_FOR_STMT if it is cleared on modified stmts, I'm not sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23940
