[PATCH] D87149: [InstCombine] erase instructions leading up to unreachable

stephan.yichao.zhao via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 9 10:04:57 PDT 2020


stephan.yichao.zhao added a comment.

In D87149#2263692 <https://reviews.llvm.org/D87149#2263692>, @nikic wrote:

>> Although executing __builtin_unreachable is undefined, removing the code before it deletes their side effects.
>
> I believe this behavior is correct. LangRef explicitly states that execution continues past a volatile store. As such, unreachable must be reached, which is undefined behavior. As such, we are free to optimize as we wish, including removing a preceding volatile store.

I think the problem is if that reaching unreachable instructions is undefined means the behavior when a program hits __builtin_unreachable is undefined and the behavior before  __builtin_unreachable is hit is also undefined.

The behavior when a program hits __builtin_unreachable is definitely undefined, because a runtime can abort or hang or keep on going. The LangRef does not define it.

However, is the behavior before  __builtin_unreachable is hit is also undefined? Does LLVM have any existing transformation or optimization examples that change behaviors before an undefined instruction?
I found some blogs: https://blog.llvm.org/posts/2011-05-13-what-every-c-programmer-should-know/ and https://blog.regehr.org/archives/213 They do not answer the question explicitly, although I found the first link says "If you're using an LLVM-based compiler, you can dereference a "volatile" null pointer to get a crash if that's what you're looking for, **since volatile loads and stores are generally not touched by the optimizer**."


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87149/new/

https://reviews.llvm.org/D87149



More information about the llvm-commits mailing list