Current implementation of getBackedgeTakenCount returns the number of iterations if the loop
exits by its latch condition and not by some side exit (like exception throw or guard). On the other
hand, nsw/nuw flags in AddRecExpr guarantee no-overflow in real loop execution. In patricular,
it can be set based on fact that we have proved that the loop always exits by guard after some iterations.
This inconsistence lures to make an assumption that if an AddRec has no-wrap flag then it will not overflow
if we make getBackedgeTakenCount iterations, and it is incorrect. It creates dangerous pitfalls, see details
of https://reviews.llvm.org/D37569 as an example. In particular, we cannot use the fact that some monotonic
predicate is true on first and last iteration to prove that it is also true on every intermediate iteration just because
the monotonicity could be proved from guard and last iteration is calculated with getBackedgeTakenCount.
To resolve this contradiction and keeping feasibility to use monotonicity to prove facts, we need to be able to prove
that an AddRecExpr does not overflow even if the looop getBackedgeTakenCount iterations (EVEN if it is impossible
and we always exit by guard before it happens). You can think of it as "let us disable all side exit, actually make this
number of iterations and see if it is overflown".
This patch introduces a function that can be used to make this check.
I'm not sure this is sound -- the backedge taken count you compute here can itself be dependent on the nuw/nsw flags, i.e. something like (this exact example may not work):
In theory the add rec for i can be proved nuw based on the guard and that can be used to upper bound the ++i u< 200 trip count to ~0u - 300 since other i would have to unsigned overflow.