When using SCEVExpander, we rely on passes to check that what they do is OK from
the point of the expander. Effectively, if they fail to do so, it is never checked.
This patch adds assert on the fact that if we need to create any instructions in SCEV
expander, it is safe to create them. Failure of this assert should be interpreted as a bug
in the pass where it happened.
The examples of passes (and fixes to them) that failed to ensure that what they do is safe are:
https://reviews.llvm.org/D39229
https://reviews.llvm.org/D39230
https://reviews.llvm.org/D39234
I think this is overtly conservative. Expanding something unsafe is a problem only if "unsafety" (in practice, today this is just division by zero) was not present in the IR before. For instance if we have %v = udiv i32 %x, %y in the IR then it is perfectly fine to getSCEV on %v and then re-expand it before or after %v since if %y was 0 then the program is undefined.