[all-commits] [llvm/llvm-project] aadaa0: [WebAssembly] Fix rethrow's index calculation (#11...

[Heejin Ahn via All-commits]

  Branch: refs/heads/release/19.x
  Home:   https://github.com/llvm/llvm-project
  Commit: aadaa00de76ed0c4987b97450dd638f63a385bed
      https://github.com/llvm/llvm-project/commit/aadaa00de76ed0c4987b97450dd638f63a385bed
  Author: Heejin Ahn <aheejin at gmail.com>
  Date:   2024-11-19 (Tue, 19 Nov 2024)

  Changed paths:
    M llvm/include/llvm/Target/TargetSelectionDAG.td
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.td
    M llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp
    M llvm/lib/Target/WebAssembly/WebAssemblyISelDAGToDAG.cpp
    M llvm/lib/Target/WebAssembly/WebAssemblyInstrControl.td
    M llvm/lib/Target/WebAssembly/WebAssemblyLateEHPrepare.cpp
    M llvm/lib/Target/X86/X86InstrCompiler.td
    M llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.mir
    M llvm/test/CodeGen/WebAssembly/exception-legacy.ll
    M llvm/test/CodeGen/WebAssembly/exception.mir

  Log Message:
  -----------
  [WebAssembly] Fix rethrow's index calculation (#114693)

So far we have assumed that we only rethrow the exception caught in the
innermost EH pad. This is true in code we directly generate, but after
inlining this may not be the case. For example, consider this code:
```ll
ehcleanup:
  %0 = cleanuppad ...
  call @destructor
  cleanupret from %0 unwind label %catch.dispatch
```

If `destructor` gets inlined into this function, the code can be like
```ll
ehcleanup:
  %0 = cleanuppad ...
  invoke @throwing_func
    to label %unreachale unwind label %catch.dispatch.i

catch.dispatch.i:
  catchswitch ... [ label %catch.start.i ]

catch.start.i:
  %1 = catchpad ...
  invoke @some_function
    to label %invoke.cont.i unwind label %terminate.i

invoke.cont.i:
  catchret from %1 to label %destructor.exit

destructor.exit:
  cleanupret from %0 unwind label %catch.dispatch
```

We lower a `cleanupret` into `rethrow`, which assumes it rethrows the
exception caught by the nearest dominating EH pad. But after the
inlining, the nearest dominating EH pad is not `ehcleanup` but
`catch.start.i`.

The problem exists in the same manner in the new (exnref) EH, because it
assumes the exception comes from the nearest EH pad and saves an exnref
from that EH pad and rethrows it (using `throw_ref`).

This problem can be fixed easily if `cleanupret` has the basic block
where its matching `cleanuppad` is. The bitcode instruction `cleanupret`
kind of has that info (it has a token from the `cleanuppad`), but that
info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s
`cleanupret` node does not have any arguments:

https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700
Note that `catchret` already has two basic block arguments, even though
neither of them means `catchpad`'s BB.

This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node
in ISel and uses it in the Wasm backend. Because this node is also used
in X86 backend we need to note its argument there too but nothing more
needs to change there as long as X86 doesn't need it.

---

- Details about changes in the Wasm backend:

After this PR, our pseudo `RETHROW` instruction takes a BB, which means
the EH pad whose exception it needs to rethrow. There are currently two
ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic
and the other is from `CLEANUPRET` we discussed above. In case of
`llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is
lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As
written in the comments, this PR doesn't change how this BB is computed.
The BB argument will be converted to an immediate argument as with other
control flow instructions in CFGStackify.

In case of `CLEANUPRET`, it already has a BB argument pointing to an EH
pad, so it is just converted to a `RETHROW` with the same BB argument in
LateEHPrepare. This will also be lowered to an immediate in CFGStackify
with other control flow instructions.

---

Fixes #114600.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications