0:46:58karloszi think this will be similar to incrmentally updating the ownership information
0:47:09karloszjust whack-a-mole until you get all the update locations
0:56:28karloszand i think i've found a compromise to this dreaded, recalculate everything vs incrementally update but break abstraction debate
0:57:11karloszjust provide incremental versions of each of the set-predecessor, remove-useless-instruction, reinitialize-data functions, so that each call site can use them without breaking abstraction but not recalculate info all the time too
0:57:52Bikei'm not s ure how to do set-predecessors incrementally.
1:02:38karloszthe successor's successor's predecessor list doesnt need to be modified
1:03:06Bikei mean, what if you delete an instruction and so it has no predecessors and so is dead
1:03:24Bikeand so its successors havce no predecessors, i mean
1:05:50karloszhere is how i imagine this instruction will be used: everytime you want to delete an instruction x, you get the predecessors p of that instrution x, consider the successors s of x, you delete x, then you call this reinitialize function on p and s
1:05:59karloszactually, delete-instruction should do this...
1:06:12Bikeyeah, that's fine for delete-instruction
1:06:17karloszbut the point is, there are things that make it so you need to call set-predecessors
1:06:30Bikemore complicated deletions are more complicated, is all
1:06:39karloszbut generally, if you save a little bit more information, you won't need to do it