[all-commits] [llvm/llvm-project] f89b9a: [WebAssembly] Fix: fixCallUnwindMismatches after f...

[Hood Chatham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f89b9a0792d011d41dcae0465e9e14facd073e9d
      https://github.com/llvm/llvm-project/commit/f89b9a0792d011d41dcae0465e9e14facd073e9d
  Author: Hood Chatham <roberthoodchatham at gmail.com>
  Date:   2026-04-08 (Wed, 08 Apr 2026)

  Changed paths:
    M llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp
    M llvm/test/CodeGen/WebAssembly/cfg-stackify-eh-legacy.ll
    M llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.ll
    M llvm/test/CodeGen/WebAssembly/exception-legacy.ll
    M llvm/test/CodeGen/WebAssembly/exception.ll

  Log Message:
  -----------
  [WebAssembly] Fix: fixCallUnwindMismatches after fixCatchUnwindMismatches (#187484)

`fixCallUnwindMismatches()` adds an extra try block around call sites
with incorrect unwind targets. `fixCatchUnwindMismatches()` handles
catch blocks that have incorrect next unwind destinations. Previously we
ran `fixCallUnwindMismatches()` first and then ran
`fixCatchUnwindMismatches()`. The problem is that
`fixCatchUnwindMismatches()` wraps entire try blocks which can change
the unwind destination of the calls inside. If the calls had an
incorrect unwind target to begin with, they will be wrapped already and
so the outer wrapping won't alter their unwind target. However, if they
start out with a correct unwind target, they won't get wrapped and then
that can be messed up by `fixCatchUnwindMismatches()`.

The fix is to run `fixCatchUnwindMismatches()` first.
`fixCallUnwindMismatches()` never messes up the result of
`fixCatchUnwindMismatches()` so this is the correct order.

Resolves #187302



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