A short braindump:

Benchmarking the DominatorTree batch updater is a bit difficult right now, because it doesn't get widely used. Profiling it directly produces just a lot of noise. The other problem is that the update sequences produces by LoopRotation and LoopUnswitching ten to be very short (<= 3), which won't be representative of other real-world uses.

My idea for benchmarking it is to create a new tool that reads bitcode files and turns them into new modules with IR emitted with the CFGBuilder, so that it's easy to randomly generate some update sequence and apply it on the CFG. It should be easy to add a command line parameter for specifying absolute and relative update sequence lengths, ratio of insertions to deletions, etc.

My initial benchmarks on CFGs and update sequences generated manually suggest that there isn't any obvious *static* scheduling for batch updates. This is kind of expected, as different permutations of updates affect the dynamic depth in dominator trees. Because of that, we need to find a way to estimate the intermediate depth in the domiantor tree at the update point. The general heuristic that seems to work fine in my test is to maximize the total depth where the updates start, meaning, we want to perform the updates as deep in the tree as possible. This should work by minimizing the chance of recomputing bigger subtrees, as the incremental algorithm performs tree updates that are bounded by the depth in the tree.

But at this point, I don't know how to do that, and I need more data too support my intuition and observe some properties of the incremental algorithm.