[luofang34]

Speed up f64 pow with Arm's scalar, non-FMA table-based algorithm. Lookup-assisted range reduction reduces the approximation work in its logarithm and exponential stages.

For normal-positive inputs, the measured gains are:

• 3.12× independent throughput / 2.53× dependent kernel for rebuilt WASM std::f64::powf — benchmark results.
• 2.25–3.29× throughput for direct native libm::pow calls across eight default/native CPU builds — benchmark results.

Measured WASM applications add 3.2–3.6 KB compressed. The linked reports document the benchmark prototype; this PR's portable layout and x87 correction are described below. See the full benchmark report and reproduction instructions and hosted/MCU report for other input distributions, accuracy and size results.

The proposal replaces the generic implementation in math/pow.rs on all targets, independently of arch. Its helpers and tables stay in that file, so existing source tracking, extensive MPFR tests, Miri and no-panic checks cover it. The existing tests are retained, with regression cases for signed underflow, NaN identities, subnormal logarithm reduction and table boundaries. configure.rs and shared CI are unchanged.

On x87, the logarithm's high part and the exponential reduction's shifted value are explicitly rounded to binary64, with MPFR-based regression cases.

In the six MCU configurations that passed the accuracy corpus, normal-positive throughput improved 1.17–1.55×, but special-value paths slowed and linked Flash grew by 3.4–4.0 KB (results). A smaller-code MCU fallback and its selection policy remain open for maintainer discussion; this patch uses the portable implementation everywhere.

The port retains the Arm source's MIT license and attribution. The 151,083-pair accuracy corpus observed maximum errors of 0.506 ULP for the table implementation and 0.786 ULP for the baseline. An extensive MPFR run of this revision passed 17,179,869,184 pairs. This revision passes i586 MPFR/musl and no-panic checks and Miri.

Similar table-based improvements could be explored for exp and exp2, with the exponential table extracted for shared storage. The logarithm table is pow-specific.

[tgross35]

What is the reason for only using this on specific arches? And how does precision compare?

[luofang34]

What is the reason for only using this on specific arches? And how does precision compare?

Hi @tgross35 ,

For accuracy, we've checked against the upstream MPFR harness and has a smaller observed maximum ULP. (See here)

However for MCUs, measurements showed smaller gains (1.17–1.55× on normal-positive inputs), slower special-value paths, and 3.4–4.0 KB additional Flash usage., so I'm thinking of leave these part for discussion or keeping a smaller fallback.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rustbot]

⚠️ Warning ⚠️

• The following commits have merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

  • 142ab7a

  You can start a rebase with the following commands:

  $ # rebase
  $ git pull --rebase https://github.com/rust-lang/compiler-builtins.git main
  $ git push --force-with-lease