This is analogous to D86156 (which preserves "lossy" BFI in loop
passes). Lossy means that the analysis preserved may not be up to date
with regards to new blocks that are added in loop passes, but BPI will
not contain stale pointers to basic blocks that are deleted by the loop
This is achieved through BasicBlockCallbackVH in BPI, which calls
eraseBlock that updates the data structures in BPI whenever a basic
block is deleted.
This patch does not have any changes in the upstream pipeline, since
none of the loop passes actuallyin the pipeline use BPI currently.
However, since BPI wasn't previously preserved in loop passes, In our downstreamthe loop
pipeline, we have the LoopP predication pass as part ofwas invoking BPI *on the loop passentire
manager and since BPI isn't preserved, we call BPI *on the entire function* every time it ran in an LPM. This caused massive compile time
function* every time in the LoopPredi in our downstream LPM invocation invocation. An examplewhich contained loop predication.
pipeline is: -passes='require<scalar-evolution>,require<branch-prob>,loop-mssa(loop-predication,licm,simple-loop-unswitch<nontrivial>,loop-simplifycfg)'
TODO: Add a
See updated test with an invocation of an loop-pipeline containing loop
predication and -debug-pass turned ON.