Overlap between Dominator Map and TDCC

[calebmkim]

Currently, there are two big overlaps between Dominator Map and TDCC

The first is the labeling of control statement with "ID" attributes. The main difference is that Dominator Map currently labels, every control statement, gives each control statement a unique ID, and gives if statements two IDs (BEGIN_ID and END_ID). In other words, the ID numbers will never be the same across the entire control. TDCC, on the other hand, only labels pars and enables, and "each ir::Enable gets a unique label within the context of a child of an ir::Par node". From what I can tell, this basically means the ids start over (i.e. go back to 0) for each child of a par block.

The second is the generating what Dominator Map(misleadingly and should be changed) the "predecessor map" and what TDCC calls "control exits". What "predecessor map" is really doing is mapping control statements to their last node(s), where a "node" is defined as either an invoke, enable, if guard, while guard, of "if end node". "last" node means the node that will be executed last in the control statement. For invokes and enables, the "last node" is easy: it's just itself. For while loops the "last node" is just the while guard (since that is always going to be the last thing executed) and for if statements its going to be the "if end node". For pars there will be multiple "last nodes" and for seqs you will have to take the "last node(s)" of the last control statement. This does end up helping to calculate the predecessors, which is probably why I named it "predecessor map" in the first place. I'm not quite sure what TDCC's control_exits function does. It assumes no pars (it handles those separately), invokes, or empty's, but there do seem to be some similarities w/ what I did in DominatorMap. I can look at it more later on update this when I get a stronger idea.

[sampsyo]

Thanks for noting this future work down! I just wanted to point out that at least the "ID attributes" thing could be addressed by a broader refactoring to support these IR references, as discussed in #1051.