BPI has this inherent property that once it is computed for a block's
successor, Probs data exists for all successors of the block.
However, this is not true during lossy BPI preservation in loop passes,
where BPI is updated when a block is removed, but not when a block is
added (D110438).
This patch makes BPI more relaxed in the face of incomplete information:
removing an assertion that is no longer true and not relying on Probs
data to unconditionally have the information for a successor.
The unfortunate bit is that I cannot come up with any unit tests that
trigger the failure when we have lossy BPI (even downstream, the
failures are intemittent within the loop predication pass which uses
BPI). Upstream pipeline does not have a loop pass manager invocation
that uses lossy BPI preservation, but when it does, we will definitely
trip on these issues.
clang-format: please reformat the code