[TechnoPorg]

Stabilization report

Summary

Zmmul is the integer multiplication subset of the RISC-V M extension. It enables LLVM to lower multiplications to the "MUL, MULH, MULHU, MULHSU, and (for RV64 only) MULW"¹ instructions, while keeping divisions implemented in software.

This is useful for constrained embedded applications where multiplication operations are important enough for performance to warrant a hardware implementation, but division is rarely ever performed and so the extra cost of a hardware divider cannot be justified.

Using the m target feature could result in undefined behaviour by lowering to unimplemented division instructions, but excluding it leads to noticeably worse performance because hardware multiplication can't be used. Zmmul fixes this problem by enabling only multiplication.

Tracking issue:

• None

Reference PRs:

• RISC-V: add rule about target features vs. misa extensions reference#2354 (MISA vs. target features)
• Document stabilized RISC-V zmmul target feature reference#2396 (stabilize Zmmul)

What is stabilized

-Ctarget-feature=+zmmul can now be passed without a warning. #[cfg(target_feature = "zmmul")] and #[target_feature(enable = "zmmul")] are accepted.

Feedback

Nightly use

This has been in use at $INTERNSHIP for our riscv32i-unknown-none-elf embedded project for a few months now and works as expected: LLVM lowers to multiplication instructions but not division instructions.

Coverage

There is currently no test coverage in rust-lang/rust. Given that this is just forwarded to LLVM, I think it's fair to put the test burden on LLVM and not rustc.

Tool changes

• rust-analyzer
  • Thanks to the recent addition of a target feature auto-sync, we don't need to worry about this

Type system, opsem

Sound by default?

Code with this target feature enabled is sound unless it is executed in an environment where integer multiplication instructions are not available. See some of the discussion in #162552 about whether M implies Zmmul and the guidelines around the misa register for more details on this.

It is the responsibility of the user to guarantee that the instructions are implemented.

History

• The target feature was implemented in RISC-V: Add Zmmul target feature #162552, where it was discussed that stabilization after a few weeks/months would be okay

r? beetrees
cc @RalfJung, @kraj, @sweiglbosker as participants on the previous thread
@rustbot label O-riscv

Footnotes

1. Spec: https://github.com/riscv/riscv-isa-manual/blob/20250508/src/m-st-ext.adoc#zmmul-extension-version-10 ↩

[rustbot]

Target features are being changed; ensure all ABI effects are being accounted for

cc @RalfJung

Some changes occurred in std_detect

cc @Amanieu, @folkertdev, @sayantn

[rustbot]

beetrees is currently at their maximum review capacity.
They may take a while to respond.

[RalfJung]

Would M impying Zmmul make sense?

It already does imply Zmmul.
(Please don't just delete comments, it's very confusing as email notifications have already been sent.)

[RalfJung]

Seems like a no-brainer. Nominating for t-lang.
(We have been discussing in rust-lang/rust-forge#1122 what the stabilization process for target features should be, so far without clear conclusions.)

Cc @Amanieu
@rustbot ping risc-v

[rustbot]

Hey RISC-V Group! This issue has been identified as a good "RISC-V candidate".
In case it's useful, here are some instructions for tackling these sorts of
issues. Maybe take a look?
Thanks! <3

cc @denisvasilik @kraj @sweiglbosker @TechnoPorg

[RalfJung]

@davidtwco / @BoxyUwU do you want t-compiler to be included in this FCP? We have been inconsistent about this in the past; sometimes t-compiler was included but often it was not.