[llvm] Revert "[SimplifyCFG] Deduce paths unreachable if they cause div/rem UB" (PR #137741)

[Bill Wendling via llvm-commits]

bwendling wrote:

> Internally, the notion of being able to assume that undefined behavior doesn't happen is critical to the way LLVM works. This is true no matter what constructs your language actually exposes to the user: it's critical even for "safe" code in languages like Rust. Actually, Rust leans even more heavily on undefined behavior than C/C++ with its aliasing rules.
> 
> Reverting this specific patch doesn't really get you anywhere; we have code scattered across the whole compiler making implicit and explicit assumptions, without or without control flow involved.

Yes, and like I mentioned above I know reverting this specific patch won't magically stop all side effects of how UB is treated in Clang go away. This one in particular is egregious, IMO.

Perhaps I wasn't clear, but I want to revert the offending patch and then determine how best to deal with this UB issue that doesn't involve generating bad code.

> Turning on some form of -trap-unreachable by default probably makes sense. If you want -fmaybe-trapping-divide-by-zero or something like that, that's also something to consider. (And we can maybe reconsider clang's defaults...)
> 
> Doing something about "undefined behavior" in general is a research project; nobody knows how to write a compiler without undefined behavior, or that reliably warns about undefined behavior.

I mentioned on the Linux mailing list that dealing with UB is a bit like playing Wack-A-Mole(tm); we deal with it when it comes to our attention. I'm fine with adding a new flag, automatically generating a trap, issuing a warning, all three, even more, etc. What I **don't** want to have happen is for Clang to elide UB code without the programmer noticing in some form.

https://github.com/llvm/llvm-project/pull/137741