Currently, we do not expose BPI to loop passes at all. In the old pass manager, we somehow ended up with valid BPI (at least in some circumstances); in the new one, it's invalidated before running any loop pass if either LCSSA or LoopSimplify actually make changes. If they don't make changes, then BPI is valid and available.
I'm not sure that we're going to be able to push through BPI through all loop passes, and the behaviour of an non-preserved by a loop pass function analysis worries me quite a bit. However, I think it's worth supporting at least simple cases, which is what these changes do.
Here's the reasoning by which preservation is correct for each:
- LCSSA does not modify the CFG. BPI only maps terminator instructions to data, so not modifying the CFG ensures data validity.
- LoopSimplify can insert blocks, but it does so only by splitting existing blocks and edges. This results in the interesting property that all new terminators are unconditional branches. BPI does not contain entries for such terminators. All deletions are handled via ValueHandle callbacks w/in BPI.
This avoids an invalidation between the two requires in the following trivial pass pipeline:
opt -passes="requires<branch-prob>,loop(no-op-loop),requires<branch-prob>"