Wasmtime GitHub notifications bot (Apr 03 2026 at 16:08): Wasmtime GitHub notifications bot (Apr 03 2026 at 16:08):alexcrichton requested wasmtime-compiler-reviewers for a review on PR #12951.
Wasmtime GitHub notifications bot (Apr 03 2026 at 16:08):alexcrichton opened PR #12951 from alexcrichton:riscv64-fix-uadd-overflow to bytecodealliance:main:
This commit fixes a mistake from #11583 where the implementation of
uadd_overflowon riscv64 was not correct for some inputs. This fix generates the same codegen asuadd_overflow_trapwhich is to zero-extend both inputs, perform a 64-bit add, and use the 33rd bit as the overflow flag.This sequence does notably differ from what LLVM generates. For example this input function
#[unsafe(no_mangle)] pub fn uadd_overflow(a: u64, b: u64) -> (u32, bool) { (a as u32).overflowing_add(b as u32) }generates:
uadd_overflow: addw a0, a0, a1 sext.w a1, a1 sltu a1, a0, a1 retWhile this is probably correct I find it tough to reason about how
addwproduces a sign-extended result,sext.wsign-extends one of the operands, and then an unsigned comparison is used to generate the overflow flag for an unsigned addition. Overall I felt it was easier to just match theuadd_overflow_trapcodegen.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Apr 03 2026 at 16:08):alexcrichton requested cfallin for a review on PR #12951.
Wasmtime GitHub notifications bot (Apr 03 2026 at 16:09):alexcrichton edited PR #12951:
This commit fixes a mistake from #11583 where the implementation of
uadd_overflowon riscv64 was not correct for some inputs. This fix generates the same codegen asuadd_overflow_trapwhich is to zero-extend both inputs, perform a 64-bit add, and use the 33rd bit as the overflow flag.This sequence does notably differ from what LLVM generates. For example this input function
#[unsafe(no_mangle)] pub fn uadd_overflow(a: u64, b: u64) -> (u32, bool) { (a as u32).overflowing_add(b as u32) }generates:
uadd_overflow: addw a0, a0, a1 sext.w a1, a1 sltu a1, a0, a1 retWhile this is probably correct I find it tough to reason about how
addwproduces a sign-extended result,sext.wsign-extends one of the operands, and then an unsigned comparison is used to generate the overflow flag for an unsigned addition. Overall I felt it was easier to just match theuadd_overflow_trapcodegen.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Apr 03 2026 at 16:26):cfallin submitted PR review.
Wasmtime GitHub notifications bot (Apr 03 2026 at 16:26):cfallin has enabled auto merge for PR #12951.
Wasmtime GitHub notifications bot (Apr 03 2026 at 16:32):cfallin added PR #12951 riscv64: Fix uadd_overflow for 32-bit integers to the merge queue.
Wasmtime GitHub notifications bot (Apr 03 2026 at 16:57):cfallin merged PR #12951.
Wasmtime GitHub notifications bot (Apr 03 2026 at 16:57):cfallin removed PR #12951 riscv64: Fix uadd_overflow for 32-bit integers from the merge queue.
Last updated: Apr 12 2026 at 23:10 UTC