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

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 9 20:08:34 PDT 2020


jdoerfert added a subscriber: nlopes.
jdoerfert added a comment.

In D87149#2264766 <https://reviews.llvm.org/D87149#2264766>, @chandlerc wrote:

> [...]
>
> Given that, it seems very hard to argue that a volatile memory access must not trap, and must not unwind the stack -- signal handlers are allowed to do that, and it seems like a long held valid use case for volatile access to memory is to trigger a specific signal handler. Perhaps this use case just didn't come up in the prior discussions?

I think @efriedma was initially proposing to allow volatile accesses to trap and that is what we should do here. It is not `willreturn`, for the lack of a better "attribute". That solves the problem this patch exposes, matches the expectations expressed so far, and does not require us to force additional restrictions that we might don't want. The change is makes the IR retroactively stricter, which in turn makes optimizations we did before illegal but keeps old IR valid under the new semantics.

I would say let's write an RFC and see if there are other opinions. Also, @nlopes what does alive2 think of such a proposal?


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