Skip to content

rustc: Stabilize the WebAssembly wide-arithmetic feature - #160877

Open
alexcrichton wants to merge 1 commit into
rust-lang:mainfrom
alexcrichton:stabilize-wasm-wide-arithmetic
Open

rustc: Stabilize the WebAssembly wide-arithmetic feature#160877
alexcrichton wants to merge 1 commit into
rust-lang:mainfrom
alexcrichton:stabilize-wasm-wide-arithmetic

Conversation

@alexcrichton

Copy link
Copy Markdown
Member

This commit stabilizes the wide-arithmetic target feature for WebAssembly targets. This upstream WebAssembly proposal has now reached phase 4 in the WebAssembly CG standardization process which means that it's expected to ship shortly in browsers/engines and is considered stable. This is intended to be a sibling PR to rust-lang/rust to reflect the stability of the proposal in LLVM/engines to allow users to enable this in downstream code without warnings.

To recap what wide-arithmetic is -- this is a target feature for all WebAssembly targets for Rust. This feature corresponds to the LLVM wide-arithmetic target feature and gates generation of four new instructions added in the wide-arithmetic proposal, primarily centered around 128-bit addition/subtraction and a widening 64x64-bit multiply producing a 128-bit result. This target feature has no library APIs, no impact on the Rust language, nor any impact on ABIs anywhere. The only change is that more efficient codegen is generated for some operations, primarily 128-bit multiplication. Generally speaking it's expected that users should be able to enable this feature, recompile with today's source code, and see speedups if these operations are bottlenecks.

This feature is off-by-default and requires -Ctarget-feature=... or similar to enable it. This feature will not be on-by-default for quite some time while engine support percolates and (ideally) becomes pervasive.

@rustbot

rustbot commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 10, 2026
@rustbot

rustbot commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 75 candidates
  • Random selection from 18 candidates

@alexcrichton

Copy link
Copy Markdown
Member Author

I'll note that I'm doing this initially as "just a PR" since IIRC that's the process for stabilizing minor target features, but please let me know if there's a separate process I should follow and I'd be happy to do so!

Also, I've got a sibling PR for the reference.

@JonathanBrouwer

Copy link
Copy Markdown
Contributor

I'll note that I'm doing this initially as "just a PR" since IIRC that's the process for stabilizing minor target features

Could you point me to what precedent your basing this on? (i.e. previous PRs that did the same?)
If I follow the rustc-forge literally, this would require a MCP:

Extending the behavior of a stable flag
Propose using: MCP
Approve using: Seconding
Describe the rationale for extending the behavior of the flag. Once discussion has concluded, a team member may second the proposal

(https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#what-proposalapproval-do-i-need)

But I've never reviewed a stabilization of a target feature before, so I could very well be missing something

@alexcrichton

Copy link
Copy Markdown
Member Author

My historical data point here is #131080, but I'd also be happy to go the MCP route as I suspect it won't be really all that much extra work. Do you have a preference though of MCP vs FCP-here?

@JonathanBrouwer

Copy link
Copy Markdown
Contributor

Ooh I found further on in the page

Stabilizing a target feature
Propose using: PR
Approve using: FCP
Open a PR stabilizing the target feature and once the reviewer is happy with the changes, an FCP can be started

So we should start an FCP here

This commit stabilizes the `wide-arithmetic` target feature for
WebAssembly targets. This [upstream WebAssembly proposal][repo] has
[now reached phase 4][phase] in the WebAssembly CG standardization
process which means that it's expected to ship shortly in
browsers/engines and is considered stable. This is intended to be a
sibling PR to rust-lang/rust to reflect the stability of the proposal in
LLVM/engines to allow users to enable this in downstream code without
warnings.

To recap what `wide-arithmetic` is -- this is a target feature for all
WebAssembly targets for Rust. This feature corresponds to the LLVM
`wide-arithmetic` target feature and gates generation of four new
instructions added in the [wide-arithmetic proposal][repo], primarily
centered around 128-bit addition/subtraction and a widening 64x64-bit
multiply producing a 128-bit result. This target feature has no library
APIs, no impact on the Rust language, nor any impact on ABIs anywhere.
The only change is that more efficient codegen is generated for some
operations, primarily 128-bit multiplication. Generally speaking it's
expected that users should be able to enable this feature, recompile
with today's source code, and see speedups if these operations are
bottlenecks.

This feature is off-by-default and requires `-Ctarget-feature=...` or
similar to enable it. This feature will not be on-by-default for quite
some time while engine support percolates and (ideally) becomes
pervasive.

[repo]: https://github.com/webassembly/wide-arithmetic
[phase]: WebAssembly/proposals#239
@alexcrichton
alexcrichton force-pushed the stabilize-wasm-wide-arithmetic branch from fb9ccd8 to 3a51e4d Compare August 10, 2026 20:28
@JonathanBrouwer

Copy link
Copy Markdown
Contributor

I was just gonna say I don't think we have any test coverage for the target feature, but you were a few seconds quicker :p

@alexcrichton

Copy link
Copy Markdown
Member Author

I was just gonna say I don't think we have any test coverage for the target feature

Oops yes sorry forgot to do that but reading over #131080 reminded me of the test we have for this!


Unsure if this'll work, but now that CI's green let's see:

@rfcbot fcp merge

@wesleywiser

Copy link
Copy Markdown
Member

@rfcbot fcp merge

@rust-rfcbot

rust-rfcbot commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

@wesleywiser has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rust-rfcbot rust-rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Aug 11, 2026
@traviscross traviscross added the has-reference-pr This language change has an approved Reference PR. label Aug 11, 2026
@traviscross

Copy link
Copy Markdown
Contributor

cc @rust-lang/lang @rust-lang/lang-docs @rust-lang/fls

@traviscross traviscross added the I-lang-radar Items that are on lang's radar and will need eventual work or consideration. label Aug 11, 2026
@scottmcm

Copy link
Copy Markdown
Member

Yay for a better output from https://doc.rust-lang.org/std/primitive.u64.html#method.carrying_mul_add in WASM :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. has-reference-pr This language change has an approved Reference PR. I-lang-radar Items that are on lang's radar and will need eventual work or consideration. proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants