[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