llvm.wasm.throw is inconsistently considered non-unwinding or invocable #124710

purplesyringa · 2025-01-28T07:06:36Z

Miscompiled:

void loud();

void throw_and_catch(void *ex) {
    try {
        __builtin_wasm_throw(0, ex);
    } catch (...) {
        loud();
    }
}

The generated IR is

define hidden void @throw_and_catch(void*)(ptr noundef %ex) {
entry:
  %ex.addr = alloca ptr, align 4
  store ptr %ex, ptr %ex.addr, align 4
  %0 = load ptr, ptr %ex.addr, align 4
  call void @llvm.wasm.throw(i32 0, ptr %0)
  ret void
}

without a catchpad.

https://godbolt.org/z/Po668Yxaz

Broken IR:

void loud();

void my_throw(void *ex) {
    __builtin_wasm_throw(0, ex);
}

void throw_and_catch(void *ex) {
    try {
        my_throw(ex);
    } catch (...) {
        loud();
    }
}

InlinerPass replaces

  invoke void @my_throw(void*)(ptr noundef %ex)
          to label %try.cont unwind label %catch.dispatch

(correct, working) with

  invoke void @llvm.wasm.throw(i32 0, ptr %ex)
          to label %.noexc unwind label %catch.dispatch

(broken, llvm.wasm.throw cannot be invoked), which halts the backend.

https://godbolt.org/z/rMEd1x79z

As far as I'm aware, llvm.wasm.throw is the only function that can unwind but cannot be invoked, making this troublesome for external frontends like rustc, not just for optimization passes. Ideally it would become invocable.

The text was updated successfully, but these errors were encountered:

llvmbot · 2025-02-03T16:36:55Z

@llvm/issue-subscribers-backend-webassembly

Author: Alisa Sireneva (purplesyringa)

1. Miscompiled:

void loud();

void throw_and_catch(void *ex) {
    try {
        __builtin_wasm_throw(0, ex);
    } catch (...) {
        loud();
    }
}

The generated IR is

define hidden void @<!-- -->throw_and_catch(void*)(ptr noundef %ex) {
entry:
  %ex.addr = alloca ptr, align 4
  store ptr %ex, ptr %ex.addr, align 4
  %0 = load ptr, ptr %ex.addr, align 4
  call void @<!-- -->llvm.wasm.throw(i32 0, ptr %0)
  ret void
}

without a catchpad.

https://godbolt.org/z/Po668Yxaz

Broken IR:

void loud();

void my_throw(void *ex) {
    __builtin_wasm_throw(0, ex);
}

void throw_and_catch(void *ex) {
    try {
        my_throw(ex);
    } catch (...) {
        loud();
    }
}

InlinerPass replaces

  invoke void @<!-- -->my_throw(void*)(ptr noundef %ex)
          to label %try.cont unwind label %catch.dispatch

(correct, working) with

  invoke void @<!-- -->llvm.wasm.throw(i32 0, ptr %ex)
          to label %.noexc unwind label %catch.dispatch

(broken, llvm.wasm.throw cannot be invoked), which halts the backend.

https://godbolt.org/z/rMEd1x79z

As far as I'm aware, llvm.wasm.throw is the only function that can unwind but cannot be invoked, making this troublesome for external frontends like rustc, not just for optimization passes. Ideally it would become invocable.

`llvm.wasm.throw` intrinsic can throw but it was not invokable. Not sure what the rationale was when it was first written that way, but I think at least in Emscripten's C++ exception support with the Wasm port of libunwind, `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.rethrow`, is used only within `_Unwind_RaiseException`, which is a one-liner and thus does not need an `invoke`: https://github.com/emscripten-core/emscripten/blob/720e97f76d6f19e0c6a2d6988988cfe23f0517fb/system/lib/libunwind/src/Unwind-wasm.c#L69 (`_Unwind_RaiseException` is called by `__cxa_throw`, which is generated by the `throw` C++ keyword) But this does not address other direct uses of the builtin in C++, whose use I'm not sure about but is not prohibited. Also other language frontends may need to use the builtin in different functions, which has `try`-`catch`es or destructors. This makes `llvm.wasm.throw` invokable in the backend. To do that, this adds a custom lowering routine to `SelectionDAGBuilder::visitInvoke`, like we did for `llvm.wasm.rethrow`. This does not generate `invoke`s for `__builtin_wasm_throw` yet, which will be done by a follow-up PR. Addresses llvm#124710.

Even though `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.throw`, throws, ```cpp try { __builtin_wasm_throw(0, obj); } catch (...) { } ``` does not generate `invoke`. This is because we have assumed the intrinsic cannot be invoked, which doesn't make much sense. (See llvm#128104 for the historical context) llvm#128104 made `llvm.wasm.throw` intrinsic invokable in the backend. This actually generates `invoke`s in Clang for `__builtin_wasm_throw`. While we're at it, this also generates `invoke`s for `__builtin_wasm_rethrow`, which is actually not used anywhere in C++ support. I haven't deleted it just in case in may have uses later. (For example, to support rethrow functionality that carries stack trace with exnref) Depends on llvm#128104 for the CI to pass. Fixes llvm#124710.

`llvm.wasm.throw` intrinsic can throw but it was not invokable. Not sure what the rationale was when it was first written that way, but I think at least in Emscripten's C++ exception support with the Wasm port of libunwind, `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.rethrow`, is used only within `_Unwind_RaiseException`, which is an one-liner and thus does not need an `invoke`: https://github.com/emscripten-core/emscripten/blob/720e97f76d6f19e0c6a2d6988988cfe23f0517fb/system/lib/libunwind/src/Unwind-wasm.c#L69 (`_Unwind_RaiseException` is called by `__cxa_throw`, which is generated by the `throw` C++ keyword) But this does not address other direct uses of the builtin in C++, whose use I'm not sure about but is not prohibited. Also other language frontends may need to use the builtin in different functions, which has `try`-`catch`es or destructors. This makes `llvm.wasm.throw` invokable in the backend. To do that, this adds a custom lowering routine to `SelectionDAGBuilder::visitInvoke`, like we did for `llvm.wasm.rethrow`. This does not generate `invoke`s for `__builtin_wasm_throw` yet, which will be done by a follow-up PR. Addresses #124710.

Even though `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.throw`, throws, ```cpp try { __builtin_wasm_throw(0, obj); } catch (...) { } ``` does not generate `invoke`. This is because we have assumed the intrinsic cannot be invoked, which doesn't make much sense. (See #128104 for the historical context) #128104 made `llvm.wasm.throw` intrinsic invokable in the backend. This actually generates `invoke`s in Clang for `__builtin_wasm_throw`. While we're at it, this also generates `invoke`s for `__builtin_wasm_rethrow`, which is actually not used anywhere in C++ support. I haven't deleted it just in case in may have uses later. (For example, to support rethrow functionality that carries stack trace with exnref) Depends on #128104 for the CI to pass. Fixes #124710.

llvmbot · 2025-02-25T22:32:30Z

@llvm/issue-subscribers-clang-codegen

Author: Alisa Sireneva (purplesyringa)

1. Miscompiled:

void loud();

void throw_and_catch(void *ex) {
    try {
        __builtin_wasm_throw(0, ex);
    } catch (...) {
        loud();
    }
}

The generated IR is

define hidden void @<!-- -->throw_and_catch(void*)(ptr noundef %ex) {
entry:
  %ex.addr = alloca ptr, align 4
  store ptr %ex, ptr %ex.addr, align 4
  %0 = load ptr, ptr %ex.addr, align 4
  call void @<!-- -->llvm.wasm.throw(i32 0, ptr %0)
  ret void
}

without a catchpad.

https://godbolt.org/z/Po668Yxaz

Broken IR:

void loud();

void my_throw(void *ex) {
    __builtin_wasm_throw(0, ex);
}

void throw_and_catch(void *ex) {
    try {
        my_throw(ex);
    } catch (...) {
        loud();
    }
}

InlinerPass replaces

  invoke void @<!-- -->my_throw(void*)(ptr noundef %ex)
          to label %try.cont unwind label %catch.dispatch

(correct, working) with

  invoke void @<!-- -->llvm.wasm.throw(i32 0, ptr %ex)
          to label %.noexc unwind label %catch.dispatch

(broken, llvm.wasm.throw cannot be invoked), which halts the backend.

https://godbolt.org/z/rMEd1x79z

As far as I'm aware, llvm.wasm.throw is the only function that can unwind but cannot be invoked, making this troublesome for external frontends like rustc, not just for optimization passes. Ideally it would become invocable.

Even though `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.throw`, throws, ```cpp try { __builtin_wasm_throw(0, obj); } catch (...) { } ``` does not generate `invoke`. This is because we have assumed the intrinsic cannot be invoked, which doesn't make much sense. (See llvm#128104 for the historical context) llvm#128104 made `llvm.wasm.throw` intrinsic invokable in the backend. This actually generates `invoke`s in Clang for `__builtin_wasm_throw`. While we're at it, this also generates `invoke`s for `__builtin_wasm_rethrow`, which is actually not used anywhere in C++ support. I haven't deleted it just in case in may have uses later. (For example, to support rethrow functionality that carries stack trace with exnref) Depends on llvm#128104 for the CI to pass. Fixes llvm#124710.

llvmbot · 2025-02-26T00:25:49Z

@llvm/issue-subscribers-backend-webassembly

Author: Alisa Sireneva (purplesyringa)

1. Miscompiled:

void loud();

void throw_and_catch(void *ex) {
    try {
        __builtin_wasm_throw(0, ex);
    } catch (...) {
        loud();
    }
}

The generated IR is

define hidden void @<!-- -->throw_and_catch(void*)(ptr noundef %ex) {
entry:
  %ex.addr = alloca ptr, align 4
  store ptr %ex, ptr %ex.addr, align 4
  %0 = load ptr, ptr %ex.addr, align 4
  call void @<!-- -->llvm.wasm.throw(i32 0, ptr %0)
  ret void
}

without a catchpad.

https://godbolt.org/z/Po668Yxaz

Broken IR:

void loud();

void my_throw(void *ex) {
    __builtin_wasm_throw(0, ex);
}

void throw_and_catch(void *ex) {
    try {
        my_throw(ex);
    } catch (...) {
        loud();
    }
}

InlinerPass replaces

  invoke void @<!-- -->my_throw(void*)(ptr noundef %ex)
          to label %try.cont unwind label %catch.dispatch

(correct, working) with

  invoke void @<!-- -->llvm.wasm.throw(i32 0, ptr %ex)
          to label %.noexc unwind label %catch.dispatch

(broken, llvm.wasm.throw cannot be invoked), which halts the backend.

https://godbolt.org/z/rMEd1x79z

As far as I'm aware, llvm.wasm.throw is the only function that can unwind but cannot be invoked, making this troublesome for external frontends like rustc, not just for optimization passes. Ideally it would become invocable.

aheejin · 2025-02-26T00:26:11Z

(The fix needed both #128104 and #128105, and #128104 was a wasm backend problem)

purplesyringa · 2025-02-26T08:39:43Z

Thanks a lot! Really appreciate it.

`llvm.wasm.throw` intrinsic can throw but it was not invokable. Not sure what the rationale was when it was first written that way, but I think at least in Emscripten's C++ exception support with the Wasm port of libunwind, `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.rethrow`, is used only within `_Unwind_RaiseException`, which is an one-liner and thus does not need an `invoke`: https://github.com/emscripten-core/emscripten/blob/720e97f76d6f19e0c6a2d6988988cfe23f0517fb/system/lib/libunwind/src/Unwind-wasm.c#L69 (`_Unwind_RaiseException` is called by `__cxa_throw`, which is generated by the `throw` C++ keyword) But this does not address other direct uses of the builtin in C++, whose use I'm not sure about but is not prohibited. Also other language frontends may need to use the builtin in different functions, which has `try`-`catch`es or destructors. This makes `llvm.wasm.throw` invokable in the backend. To do that, this adds a custom lowering routine to `SelectionDAGBuilder::visitInvoke`, like we did for `llvm.wasm.rethrow`. This does not generate `invoke`s for `__builtin_wasm_throw` yet, which will be done by a follow-up PR. Addresses llvm#124710.

Even though `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.throw`, throws, ```cpp try { __builtin_wasm_throw(0, obj); } catch (...) { } ``` does not generate `invoke`. This is because we have assumed the intrinsic cannot be invoked, which doesn't make much sense. (See llvm#128104 for the historical context) llvm#128104 made `llvm.wasm.throw` intrinsic invokable in the backend. This actually generates `invoke`s in Clang for `__builtin_wasm_throw`. While we're at it, this also generates `invoke`s for `__builtin_wasm_rethrow`, which is actually not used anywhere in C++ support. I haven't deleted it just in case in may have uses later. (For example, to support rethrow functionality that carries stack trace with exnref) Depends on llvm#128104 for the CI to pass. Fixes llvm#124710.

`llvm.wasm.throw` intrinsic can throw but it was not invokable. Not sure what the rationale was when it was first written that way, but I think at least in Emscripten's C++ exception support with the Wasm port of libunwind, `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.rethrow`, is used only within `_Unwind_RaiseException`, which is an one-liner and thus does not need an `invoke`: https://github.com/emscripten-core/emscripten/blob/720e97f76d6f19e0c6a2d6988988cfe23f0517fb/system/lib/libunwind/src/Unwind-wasm.c#L69 (`_Unwind_RaiseException` is called by `__cxa_throw`, which is generated by the `throw` C++ keyword) But this does not address other direct uses of the builtin in C++, whose use I'm not sure about but is not prohibited. Also other language frontends may need to use the builtin in different functions, which has `try`-`catch`es or destructors. This makes `llvm.wasm.throw` invokable in the backend. To do that, this adds a custom lowering routine to `SelectionDAGBuilder::visitInvoke`, like we did for `llvm.wasm.rethrow`. This does not generate `invoke`s for `__builtin_wasm_throw` yet, which will be done by a follow-up PR. Addresses llvm#124710.

Even though `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.throw`, throws, ```cpp try { __builtin_wasm_throw(0, obj); } catch (...) { } ``` does not generate `invoke`. This is because we have assumed the intrinsic cannot be invoked, which doesn't make much sense. (See llvm#128104 for the historical context) llvm#128104 made `llvm.wasm.throw` intrinsic invokable in the backend. This actually generates `invoke`s in Clang for `__builtin_wasm_throw`. While we're at it, this also generates `invoke`s for `__builtin_wasm_rethrow`, which is actually not used anywhere in C++ support. I haven't deleted it just in case in may have uses later. (For example, to support rethrow functionality that carries stack trace with exnref) Depends on llvm#128104 for the CI to pass. Fixes llvm#124710.

`llvm.wasm.throw` intrinsic can throw but it was not invokable. Not sure what the rationale was when it was first written that way, but I think at least in Emscripten's C++ exception support with the Wasm port of libunwind, `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.rethrow`, is used only within `_Unwind_RaiseException`, which is an one-liner and thus does not need an `invoke`: https://github.com/emscripten-core/emscripten/blob/720e97f76d6f19e0c6a2d6988988cfe23f0517fb/system/lib/libunwind/src/Unwind-wasm.c#L69 (`_Unwind_RaiseException` is called by `__cxa_throw`, which is generated by the `throw` C++ keyword) But this does not address other direct uses of the builtin in C++, whose use I'm not sure about but is not prohibited. Also other language frontends may need to use the builtin in different functions, which has `try`-`catch`es or destructors. This makes `llvm.wasm.throw` invokable in the backend. To do that, this adds a custom lowering routine to `SelectionDAGBuilder::visitInvoke`, like we did for `llvm.wasm.rethrow`. This does not generate `invoke`s for `__builtin_wasm_throw` yet, which will be done by a follow-up PR. Addresses llvm#124710.

Even though `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.throw`, throws, ```cpp try { __builtin_wasm_throw(0, obj); } catch (...) { } ``` does not generate `invoke`. This is because we have assumed the intrinsic cannot be invoked, which doesn't make much sense. (See llvm#128104 for the historical context) llvm#128104 made `llvm.wasm.throw` intrinsic invokable in the backend. This actually generates `invoke`s in Clang for `__builtin_wasm_throw`. While we're at it, this also generates `invoke`s for `__builtin_wasm_rethrow`, which is actually not used anywhere in C++ support. I haven't deleted it just in case in may have uses later. (For example, to support rethrow functionality that carries stack trace with exnref) Depends on llvm#128104 for the CI to pass. Fixes llvm#124710.

`llvm.wasm.throw` intrinsic can throw but it was not invokable. Not sure what the rationale was when it was first written that way, but I think at least in Emscripten's C++ exception support with the Wasm port of libunwind, `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.rethrow`, is used only within `_Unwind_RaiseException`, which is an one-liner and thus does not need an `invoke`: https://github.com/emscripten-core/emscripten/blob/720e97f76d6f19e0c6a2d6988988cfe23f0517fb/system/lib/libunwind/src/Unwind-wasm.c#L69 (`_Unwind_RaiseException` is called by `__cxa_throw`, which is generated by the `throw` C++ keyword) But this does not address other direct uses of the builtin in C++, whose use I'm not sure about but is not prohibited. Also other language frontends may need to use the builtin in different functions, which has `try`-`catch`es or destructors. This makes `llvm.wasm.throw` invokable in the backend. To do that, this adds a custom lowering routine to `SelectionDAGBuilder::visitInvoke`, like we did for `llvm.wasm.rethrow`. This does not generate `invoke`s for `__builtin_wasm_throw` yet, which will be done by a follow-up PR. Addresses llvm#124710.

Even though `__builtin_wasm_throw`, which is lowered down to `llvm.wasm.throw`, throws, ```cpp try { __builtin_wasm_throw(0, obj); } catch (...) { } ``` does not generate `invoke`. This is because we have assumed the intrinsic cannot be invoked, which doesn't make much sense. (See llvm#128104 for the historical context) llvm#128104 made `llvm.wasm.throw` intrinsic invokable in the backend. This actually generates `invoke`s in Clang for `__builtin_wasm_throw`. While we're at it, this also generates `invoke`s for `__builtin_wasm_rethrow`, which is actually not used anywhere in C++ support. I haven't deleted it just in case in may have uses later. (For example, to support rethrow functionality that carries stack trace with exnref) Depends on llvm#128104 for the CI to pass. Fixes llvm#124710.

llvmbot added the new issue label Jan 28, 2025

purplesyringa mentioned this issue Jan 28, 2025

LLVM assertion failure on Wasm exceptions rust-lang/rust#135665

Open

dtcxzyw added miscompilation llvm:optimizations backend:WebAssembly and removed new issue labels Feb 3, 2025

aheejin self-assigned this Feb 19, 2025

aheejin mentioned this issue Feb 21, 2025

[WebAssembly] Make llvm.wasm.throw invokable #128104

Merged

aheejin mentioned this issue Feb 21, 2025

[WebAssembly] Generate invokes with llvm.wasm.(re)throw #128105

Merged

aheejin closed this as completed in #128105 Feb 25, 2025

EugeneZelenko added clang:codegen IR generation bugs: mangling, exceptions, etc. and removed backend:WebAssembly llvm:optimizations labels Feb 25, 2025

aheejin added the backend:WebAssembly label Feb 26, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

llvm.wasm.throw is inconsistently considered non-unwinding or invocable #124710

llvm.wasm.throw is inconsistently considered non-unwinding or invocable #124710

purplesyringa commented Jan 28, 2025 •

edited

Loading

llvmbot commented Feb 3, 2025

llvmbot commented Feb 25, 2025

llvmbot commented Feb 26, 2025

aheejin commented Feb 26, 2025 •

edited

Loading

purplesyringa commented Feb 26, 2025

llvm.wasm.throw is inconsistently considered non-unwinding or invocable #124710

llvm.wasm.throw is inconsistently considered non-unwinding or invocable #124710

Comments

purplesyringa commented Jan 28, 2025 • edited Loading

llvmbot commented Feb 3, 2025

llvmbot commented Feb 25, 2025

llvmbot commented Feb 26, 2025

aheejin commented Feb 26, 2025 • edited Loading

purplesyringa commented Feb 26, 2025

purplesyringa commented Jan 28, 2025 •

edited

Loading

aheejin commented Feb 26, 2025 •

edited

Loading