[PATCH] D139883: [llvm][CallBrPrepare] add llvm.callbr.landingpad intrinsic

[Nick Desaulniers via Phabricator via llvm-commits]

nickdesaulniers added a comment.

In D139883#4011907 <https://reviews.llvm.org/D139883#4011907>, @void wrote:

> As we talked before, I *really* hate the use of an intrinsic here. We used an intrinsic for the old exception handling and it was nothing but buggy. Theoretically they work just fine, but the can't take into account issues due to inlining, block splitting, and other code motion changes (at least not without a hefty dose of special checks throughout the compiler). If we use an intrinsic here, I believe we're just going to revisit the errors of the past.

The use of an instruction was tried here: https://reviews.llvm.org/D139565.

Specifically, please see the feedback:

- https://reviews.llvm.org/D139565#3979289
- https://reviews.llvm.org/D139565#3979747
- https://reviews.llvm.org/D139565#3979936

While I agree with your points about intrinsic vs instruction; with the approach of the series (as mentioned in the RFC <https://discourse.llvm.org/t/rfc-syncing-asm-goto-with-outputs-with-gcc/65453/8?u=nickdesaulniers>), I'll note that the intrinsic doesn't live long enough to be relevant to inlining, block splitting, or other code motion changes. It is produced by callbrprepare shortly before being consumed by selectiondag.

Please see the pipeline test changes in https://reviews.llvm.org/D140180 to get a sense of the pass "distance" between Prepare callbr (which introduces these intrinsics) and <arch> DAG->DAG Pattern Instruction Selection which consumes them.

I need you (@void) to be in agreement with @efriedma  as the feedback around instruction vs intrinsic is giving me whiplash in code review. It's up to you two to agree; I can't have you reject intrinsics while @efriedma rejects instructions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139883