Expose algebraic floating point intrinsics #136457

calder · 2025-02-03T01:18:15Z

Problem

A stable Rust implementation of a simple dot product is 8x slower than C++ on modern x86-64 CPUs. The root cause is an inability to let the compiler reorder floating point operations for better vectorization.

See https://github.com/calder/dot-bench for benchmarks. Measurements below were performed on a i7-10875H.

C++: 10us ✅

With Clang 18.1.3 and -O2 -march=haswell:

C++	Assembly
float dot(float a, float b, size_t len) { #pragma clang fp reassociate(on) float sum = 0.0; for (size_t i = 0; i < len; ++i) { sum += a[i] * b[i]; } return sum; }

Nightly Rust: 10us ✅

With rustc 1.86.0-nightly (8239a37) and -C opt-level=3 -C target-feature=+avx2,+fma:

Rust	Assembly
fn dot(a: &[f32], b: &[f32]) -> f32 { let mut sum = 0.0; for i in 0..a.len() { sum = fadd_algebraic(sum, fmul_algebraic(a[i], b[i])); } sum }

Stable Rust: 84us ❌

With rustc 1.84.1 (e71f9a9) and -C opt-level=3 -C target-feature=+avx2,+fma:

Rust	Assembly
fn dot(a: &[f32], b: &[f32]) -> f32 { let mut sum = 0.0; for i in 0..a.len() { sum += a[i] * b[i]; } sum }

Proposed Change

Add core::intrinsics::f*_algebraic wrappers to f16, f32, f64, and f128 gated on a new float_algebraic feature.

Alternatives Considered

#21690 has a lot of good discussion of various options for supporting fast math in Rust, but is still open a decade later because any choice that opts in more than individual operations is ultimately contrary to Rust's design principles.

In the mean time, processors have evolved and we're leaving major performance on the table by not supporting vectorization. We shouldn't make users choose between an unstable compiler and an 8x performance hit.

References

try-job: x86_64-gnu-nopt
try-job: x86_64-gnu-aux

rustbot · 2025-02-03T01:18:24Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thomcc (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

rustbot · 2025-02-03T01:18:26Z

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @rust-lang/wg-const-eval

library/std/src/f32.rs

calder · 2025-02-03T07:36:09Z

Thanks for the speedy review @saethlin! I had a couple questions:

Should we add these methods to f16 and f128 as well?
Are intrinsic wrappers tested explicitly? I see tests for the intrinsics themselves but not for other wrappers.

RalfJung · 2025-02-03T07:46:43Z

Thanks for the PR! Going through the usual process, the first step would be a t-libs-api ACP to gauge the team's thinking on whether and how this should be exposed. This PR cannot land before a corresponding FCP has been accepted.

RalfJung · 2025-02-03T08:04:47Z

In terms of tests, usually we have doc tests. Also, given that the semantics are far from obvious (these operations are nondeterministic!), they need to be documented more carefully - probably in some central location, which is then referenced from everywhere.

calder · 2025-02-03T08:13:26Z

@RalfJung: Thanks for the quick response!

Created ACP here: ACP: Expose algebraic floating point intrinsics libs-team#532
Do you have a suggestion for a good central place to document these methods?

RalfJung · 2025-02-03T10:29:49Z

https://doc.rust-lang.org/nightly/std/primitive.f32.html seems like a good place, that's where we already document everything special around NaNs. So a new section on algebraic operations there would probably be a good fit.

calder · 2025-02-04T03:09:38Z

Changes

Added f16 and f128 methods as requested by @tgross35 here.
Renamed to algebraic_*() to match checked_*() as requested by @tgross35 here.
Added central documentation with verbage suggested by @RalfJung here.

library/core/src/intrinsics/mod.rs

library/core/src/primitive_docs.rs

@tgross35

Requested by @tgross35 on rust-lang#136457 (comment)

tgross35 · 2025-02-04T23:36:22Z

I don't see an existing codegen test for the intrinsics so these should probably get one. https://github.com/rust-lang/rust/tree/3f33b30e19b7597a3acbca19e46d9e308865a0fe/tests/codegen/float would be a reasonable home.

For reference, this would just be a file containing functions like this for each of the new methods, in order to verify the flags that we expect are getting set:

// CHECK-LABEL: float @f32_algebraic_add(
#[no_mangle]
pub fn f32_algebraic_add(a: f32, b: f32) -> f32 {
    // CHECK: fadd reassoc nsz arcp contract float %a, %b
    a.algebraic_add(b)
}

rustbot · 2025-02-05T08:01:59Z

The Miri subtree was changed

cc @rust-lang/miri

src/tools/miri/tests/pass/float.rs

calder · 2025-02-05T08:09:08Z

tests/codegen/float/f128-algebraic.rs

+// CHECK-LABEL: fp128 @f128_algebraic_add(
+#[no_mangle]
+pub fn f128_algebraic_add(a: f128, b: f128) -> f128 {
+    // CHECK: fadd reassoc nsz arcp contract fp128 {{(%a, %b)|(%b, %a)}}


The addition and multiplication cases both end up as %b, %a rather than %a, %b which surprised me but isn't incorrect. I opted to allow either in case behavior changes in the future.

tests/codegen/float/f128-algebraic.rs

tgross35 · 2025-02-05T08:47:05Z

This looks pretty reasonable to me but all the public functions should get some examples. I think it may also be good to give a small demo of how this may work at the end of the new "Algebraic operators" section, e.g.:

For example, the below:

```
x = x.algebraic_add(x, a.algebraic_mul(b));
```

May be rewritten as either of the following:

```
x = x + (a * b); // As written
x = (a * b) + x; // Reordered to allow using a single `fma`
```

calder · 2025-02-05T14:56:51Z

Per function examples

Did you have specific examples in mind? I'm struggling to think of ones that aren't repetitive / low signal-to-noise (i.e. assert this algebraic add is approximately equal to a normal add). Should we instead link to the central documentation and test approximate equality of each of the ops in normal tests like this so they don't clutter the documentation?

Central example

Made a couple small edits for brevity. How's this look?

tgross35 · 2025-03-11T20:37:31Z

@bors try

I think you should be able to run ./x miri library

bors · 2025-03-11T20:38:42Z

⌛ Trying commit 0151a01 with merge dabe80a...

Expose algebraic floating point intrinsics # Problem A stable Rust implementation of a simple dot product is 8x slower than C++ on modern x86-64 CPUs. The root cause is an inability to let the compiler reorder floating point operations for better vectorization. See https://github.com/calder/dot-bench for benchmarks. Measurements below were performed on a i7-10875H. ### C++: 10us ✅ With Clang 18.1.3 and `-O2 -march=haswell`: <table> <tr> <th>C++</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="cc"> float dot(float *a, float *b, size_t len) { #pragma clang fp reassociate(on) float sum = 0.0; for (size_t i = 0; i < len; ++i) { sum += a[i] * b[i]; } return sum; } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/739573c0-380a-4d84-9fd9-141343ce7e68" /> </td> </tr> </table> ### Nightly Rust: 10us ✅ With rustc 1.86.0-nightly (8239a37) and `-C opt-level=3 -C target-feature=+avx2,+fma`: <table> <tr> <th>Rust</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="rust"> fn dot(a: &[f32], b: &[f32]) -> f32 { let mut sum = 0.0; for i in 0..a.len() { sum = fadd_algebraic(sum, fmul_algebraic(a[i], b[i])); } sum } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/9dcf953a-2cd7-42f3-bc34-7117de4c5fb9" /> </td> </tr> </table> ### Stable Rust: 84us ❌ With rustc 1.84.1 (e71f9a9) and `-C opt-level=3 -C target-feature=+avx2,+fma`: <table> <tr> <th>Rust</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="rust"> fn dot(a: &[f32], b: &[f32]) -> f32 { let mut sum = 0.0; for i in 0..a.len() { sum += a[i] * b[i]; } sum } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/936a1f7e-33e4-4ff8-a732-c3cdfe068dca" /> </td> </tr> </table> # Proposed Change Add `core::intrinsics::f*_algebraic` wrappers to `f16`, `f32`, `f64`, and `f128` gated on a new `float_algebraic` feature. # Alternatives Considered rust-lang#21690 has a lot of good discussion of various options for supporting fast math in Rust, but is still open a decade later because any choice that opts in more than individual operations is ultimately contrary to Rust's design principles. In the mean time, processors have evolved and we're leaving major performance on the table by not supporting vectorization. We shouldn't make users choose between an unstable compiler and an 8x performance hit. # References * rust-lang#21690 * rust-lang/libs-team#532 * rust-lang#136469 * https://github.com/calder/dot-bench * https://www.felixcloutier.com/x86/vfmadd132ps:vfmadd213ps:vfmadd231ps try-job: x86_64-gnu-nopt try-job: x86_64-gnu-aux

bors · 2025-03-11T22:16:24Z

💔 Test failed - checks-actions

tgross35 · 2025-03-11T22:37:47Z

@bors delegate+ for @bors try, just don't merge it (I'll take a final look once things pass)

tgross35 · 2025-03-12T20:09:33Z

@bors try

It's a bit better to use --keep-base when you rebase locally to squash, that way GH shows a diff of only relevant things that changed. Unfortunately GH has the limitation that if the push includes an actual rebase onto latest (sometimes unavoidable ofc), then the "compare" link is pretty unhelpful e.g. https://github.com/rust-lang/rust/compare/53944e53dca5f93f1559b3914470c61dda2c350c..dfd4b6cddf5b2a3936492fe5c7cb97198fec3761

Expose algebraic floating point intrinsics # Problem A stable Rust implementation of a simple dot product is 8x slower than C++ on modern x86-64 CPUs. The root cause is an inability to let the compiler reorder floating point operations for better vectorization. See https://github.com/calder/dot-bench for benchmarks. Measurements below were performed on a i7-10875H. ### C++: 10us ✅ With Clang 18.1.3 and `-O2 -march=haswell`: <table> <tr> <th>C++</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="cc"> float dot(float *a, float *b, size_t len) { #pragma clang fp reassociate(on) float sum = 0.0; for (size_t i = 0; i < len; ++i) { sum += a[i] * b[i]; } return sum; } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/739573c0-380a-4d84-9fd9-141343ce7e68" /> </td> </tr> </table> ### Nightly Rust: 10us ✅ With rustc 1.86.0-nightly (8239a37) and `-C opt-level=3 -C target-feature=+avx2,+fma`: <table> <tr> <th>Rust</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="rust"> fn dot(a: &[f32], b: &[f32]) -> f32 { let mut sum = 0.0; for i in 0..a.len() { sum = fadd_algebraic(sum, fmul_algebraic(a[i], b[i])); } sum } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/9dcf953a-2cd7-42f3-bc34-7117de4c5fb9" /> </td> </tr> </table> ### Stable Rust: 84us ❌ With rustc 1.84.1 (e71f9a9) and `-C opt-level=3 -C target-feature=+avx2,+fma`: <table> <tr> <th>Rust</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="rust"> fn dot(a: &[f32], b: &[f32]) -> f32 { let mut sum = 0.0; for i in 0..a.len() { sum += a[i] * b[i]; } sum } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/936a1f7e-33e4-4ff8-a732-c3cdfe068dca" /> </td> </tr> </table> # Proposed Change Add `core::intrinsics::f*_algebraic` wrappers to `f16`, `f32`, `f64`, and `f128` gated on a new `float_algebraic` feature. # Alternatives Considered rust-lang#21690 has a lot of good discussion of various options for supporting fast math in Rust, but is still open a decade later because any choice that opts in more than individual operations is ultimately contrary to Rust's design principles. In the mean time, processors have evolved and we're leaving major performance on the table by not supporting vectorization. We shouldn't make users choose between an unstable compiler and an 8x performance hit. # References * rust-lang#21690 * rust-lang/libs-team#532 * rust-lang#136469 * https://github.com/calder/dot-bench * https://www.felixcloutier.com/x86/vfmadd132ps:vfmadd213ps:vfmadd231ps try-job: x86_64-gnu-nopt try-job: x86_64-gnu-aux

bors · 2025-03-12T20:10:46Z

⌛ Trying commit dfd4b6c with merge 2d8ed6b...

tgross35 · 2025-03-12T20:16:45Z

library/std/tests/floats/f32.rs

+#[test]
+fn test_algebraic() {
+    let a: f32 = 123.0;
+    let b: f32 = 456.0;
+
+    assert_approx_eq!(a.algebraic_add(b), a + b, 1e-2);
+    assert_approx_eq!(a.algebraic_sub(b), a - b, 1e-2);
+    assert_approx_eq!(a.algebraic_mul(b), a * b, 1e-1);
+    assert_approx_eq!(a.algebraic_div(b), a / b, 1e-5);
+    assert_approx_eq!(a.algebraic_rem(b), a % b, 1e-2);
+}


What is actually going on that causes these tests to fail? a + b should be 579.0, but the result is 579.0011. Afaict none of the algebraic effects can come into play here, so shouldn't the result be exact?

@LorrensP-2158466 @RalfJung can confirm but I assume this is from rust-lang/miri@f5330d0 since this works under ./x test but fails under ./x miri:

assert_eq!(a.algebraic_add(b), 579.0); assert_eq!(b.algebraic_add(a), 579.0);

Would it make sense to specialize this test for MIRI vs. non-MIRI and assert exact values in the non-MIRI variant?

Here's what that could look like: 6ab3fec

Typing on my phone, so I'm sorry in advance).

In a PR a while ago I introduced some extra non-determinism on floating point operations with no specified precision. Sometime later Ralf disabled these because they failed tests in std lib and others. But I think not the algebraic ones. These get a 16ULP error on top of the host error.

There is new PR where we are working on lowering these errors and accounting for this in the rust tests.

I think the best thing to do is just disabling this ULP error everywhere and take this on in the current pr or a follow up.

But Ralf knows best ofc ;)

@LorrensP-2158466: Thanks! Re:

I think the best thing to do is just disabling this ULP error everywhere and take this on in the current pr or a follow up.

Do you mean revert 622e8f4 in its entirety, or temporarily make apply_random_float_error_ulp() a noop?

Updated. How's 8ac2e73 look? Should we also update these for consistency or leave them as is?

rust/src/tools/miri/src/intrinsics/mod.rs

Line 252 in 716dd22

// Apply a relative error of 16ULP to introduce some non-determinism

rust/src/tools/miri/src/intrinsics/mod.rs

Line 288 in 716dd22

// Apply a relative error of 16ULP to introduce some non-determinism

rust/src/tools/miri/src/intrinsics/mod.rs

Line 503 in 716dd22

/// Applies a random 16ULP floating point error to `val` and returns the new value.

Not sure what you are asking about the error terms?

Sorry, I was asking if there's a constant or helper I should use instead of hardcoding absolute error terms in these assert_approx_eq() calls. I don't see any that make sense though.

Should we also update these for consistency or leave them as is?

There's another PR touching those already (#138062), so please don't touch them here to avoid conflicts.

Sorry, I was asking if there's a constant or helper I should use instead of hardcoding absolute error terms in these assert_approx_eq() calls. I don't see any that make sense though.

There's a default of 1e-5 or so, but for f32 values on the order of 100000, that's like less than 1 ULP or so, hence it doesn't work for these tests.

Copy, thanks! All good as is then. I'll squash so we can get this merged.

this test can legitimately fail without Miri.

Do you mean within the limits of what we document, or in practice with what we currently have? I don't think any of reassoc nsz arcp contract allow imprecise results for only a single float op, with the possible exception of arcp.

Fair, I should have been more clear -- I mean within the limits of the spec.

bors · 2025-03-12T22:00:16Z

☀️ Try build successful - checks-actions
Build commit: 2d8ed6b (2d8ed6b4bf07905ce9e8b131b366708f273717c0)

leonardo-m · 2025-03-13T00:11:41Z

By they way, in my codebase I use something minimal like this:

#[derive(Copy, Clone, Default)]
#[repr(transparent)]
struct Af64(pub f64);

impl Af64 {
    const ZERO: Af64 = Af64(0.0);
    const ONE: Af64 = Af64(1.0);
    fn from(x: i32) -> Self { Self(f64::from(x)) }
}

impl Add for Af64 {
    type Output = Self;

    #[inline]
    fn add(self, other: Self) -> Self {
        Self(fadd_algebraic(self.0, other.0))
    }
}

impl Sub for Af64 {
    type Output = Self;

    #[inline]
    fn sub(self, other: Self) -> Self {
        Self(fsub_algebraic(self.0, other.0))
    }
}

impl Mul for Af64 {
    type Output = Self;

    #[inline]
    fn mul(self, other: Self) -> Self {
        Self(fmul_algebraic(self.0, other.0))
    }
}

impl Div for Af64 {
    type Output = Self;

    #[inline]
    fn div(self, other: Self) -> Self {
        Self(fdiv_algebraic(self.0, other.0))
    }
}

impl Rem for Af64 {
    type Output = Self;

    #[inline]
    fn rem(self, other: Self) -> Self {
        Self(frem_algebraic(self.0, other.0))
    }
}

calder · 2025-03-29T17:16:26Z

Squashed with --keep-base and rebased past merge conflict but accidentally broke Github history again. Sorry!

RalfJung · 2025-03-29T17:58:48Z

We explicitly do not guarantee an exact value so it seems odd to have a test that checks for an exact value...

calder · 2025-03-31T17:56:00Z

@tgross35: #136457 (comment) resolved, ready to merge whenever you are!

tgross35 · 2025-04-02T19:03:33Z

@bors try

Expose algebraic floating point intrinsics # Problem A stable Rust implementation of a simple dot product is 8x slower than C++ on modern x86-64 CPUs. The root cause is an inability to let the compiler reorder floating point operations for better vectorization. See https://github.com/calder/dot-bench for benchmarks. Measurements below were performed on a i7-10875H. ### C++: 10us ✅ With Clang 18.1.3 and `-O2 -march=haswell`: <table> <tr> <th>C++</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="cc"> float dot(float *a, float *b, size_t len) { #pragma clang fp reassociate(on) float sum = 0.0; for (size_t i = 0; i < len; ++i) { sum += a[i] * b[i]; } return sum; } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/739573c0-380a-4d84-9fd9-141343ce7e68" /> </td> </tr> </table> ### Nightly Rust: 10us ✅ With rustc 1.86.0-nightly (8239a37) and `-C opt-level=3 -C target-feature=+avx2,+fma`: <table> <tr> <th>Rust</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="rust"> fn dot(a: &[f32], b: &[f32]) -> f32 { let mut sum = 0.0; for i in 0..a.len() { sum = fadd_algebraic(sum, fmul_algebraic(a[i], b[i])); } sum } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/9dcf953a-2cd7-42f3-bc34-7117de4c5fb9" /> </td> </tr> </table> ### Stable Rust: 84us ❌ With rustc 1.84.1 (e71f9a9) and `-C opt-level=3 -C target-feature=+avx2,+fma`: <table> <tr> <th>Rust</th> <th>Assembly</th> </tr> <tr> <td> <pre lang="rust"> fn dot(a: &[f32], b: &[f32]) -> f32 { let mut sum = 0.0; for i in 0..a.len() { sum += a[i] * b[i]; } sum } </pre> </td> <td> <img src="https://github.com/user-attachments/assets/936a1f7e-33e4-4ff8-a732-c3cdfe068dca" /> </td> </tr> </table> # Proposed Change Add `core::intrinsics::f*_algebraic` wrappers to `f16`, `f32`, `f64`, and `f128` gated on a new `float_algebraic` feature. # Alternatives Considered rust-lang#21690 has a lot of good discussion of various options for supporting fast math in Rust, but is still open a decade later because any choice that opts in more than individual operations is ultimately contrary to Rust's design principles. In the mean time, processors have evolved and we're leaving major performance on the table by not supporting vectorization. We shouldn't make users choose between an unstable compiler and an 8x performance hit. # References * rust-lang#21690 * rust-lang/libs-team#532 * rust-lang#136469 * https://github.com/calder/dot-bench * https://www.felixcloutier.com/x86/vfmadd132ps:vfmadd213ps:vfmadd231ps try-job: x86_64-gnu-nopt try-job: x86_64-gnu-aux

bors · 2025-04-02T19:04:46Z

⌛ Trying commit 99a96f4 with merge 14c0dd4...

rust-log-analyzer · 2025-04-02T20:40:57Z

The job x86_64-gnu-aux failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

file:.git/config remote.origin.url=https://github.com/rust-lang-ci/rust
file:.git/config remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
file:.git/config gc.auto=0
file:.git/config http.https://github.com/.extraheader=AUTHORIZATION: basic ***
file:.git/config branch.try.remote=origin
file:.git/config branch.try.merge=refs/heads/try
file:.git/config remote.upstream.url=https://github.com/rust-lang/rust
file:.git/config remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
file:.git/config submodule.library/backtrace.active=true
file:.git/config submodule.library/backtrace.url=https://github.com/rust-lang/backtrace-rs.git
file:.git/config submodule.library/stdarch.active=true
---
failures:

---- f16::test_algebraic stdout ----

thread 'f16::test_algebraic' panicked at library/std/tests/floats/f16.rs:964:5:
0x7ade is not approximately equal to 0x7ad9 (threshold 100.0, difference 0x5900)


failures:
    f16::test_algebraic

test result: FAILED. 154 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 28.62s

error: test failed, to rerun pass `-p std --test floats`
Build completed unsuccessfully in 0:05:37
make: *** [Makefile:57: check-aux] Error 1
  local time: Wed Apr  2 20:40:48 UTC 2025
  network time: Wed, 02 Apr 2025 20:40:48 GMT
##[error]Process completed with exit code 2.
Post job cleanup.

bors · 2025-04-02T20:41:31Z

💔 Test failed - checks-actions

RalfJung · 2025-04-03T08:53:55Z

If you prefer you can remove the non-determinism from the algebraic operations in Miri and we'll figure out the best way to deal with that in a follow-up PR. We should figure this out before stabilization to ensure we have a coherent semantics, but it doesn't have to all be fully done in the first PR.

rustbot assigned thomcc Feb 3, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Feb 3, 2025

saethlin reviewed Feb 3, 2025

View reviewed changes

library/std/src/f32.rs Outdated Show resolved Hide resolved

saethlin reviewed Feb 3, 2025

View reviewed changes

library/std/src/f32.rs Outdated Show resolved Hide resolved

This was referenced Feb 3, 2025

Tracking Issue for algebraic floating point operations #136468

Closed

Tracking Issue for algebraic floating point methods #136469

Open

calder mentioned this pull request Feb 3, 2025

ACP: Expose algebraic floating point intrinsics rust-lang/libs-team#532

Closed

4 tasks

tgross35 reviewed Feb 4, 2025

View reviewed changes

library/core/src/intrinsics/mod.rs Show resolved Hide resolved

tgross35 reviewed Feb 4, 2025

View reviewed changes

library/core/src/primitive_docs.rs Outdated Show resolved Hide resolved

calder added a commit to calder/rust that referenced this pull request Feb 4, 2025

Add rough expectations to algebraic operator docs.

b3132c2

Requested by @tgross35 on rust-lang#136457 (comment)

calder commented Feb 5, 2025

View reviewed changes

src/tools/miri/tests/pass/float.rs Outdated Show resolved Hide resolved

calder commented Feb 5, 2025

View reviewed changes

tgross35 reviewed Feb 5, 2025

View reviewed changes

tests/codegen/float/f128-algebraic.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

calder force-pushed the master branch from 66b78d2 to 0151a01 Compare March 11, 2025 19:38

This comment has been minimized.

Sign in to view

calder force-pushed the master branch from 53944e5 to dfd4b6c Compare March 12, 2025 16:22

tgross35 reviewed Mar 12, 2025

View reviewed changes

calder force-pushed the master branch from 6ab3fec to d2557b1 Compare March 29, 2025 17:01

calder closed this Mar 29, 2025

calder force-pushed the master branch from d2557b1 to 5cc6072 Compare March 29, 2025 17:14

calder reopened this Mar 29, 2025

Expose algebraic floating point intrinsics

99a96f4

calder force-pushed the master branch from 8ac2e73 to 99a96f4 Compare March 31, 2025 17:54

LorrensP-2158466 mentioned this pull request Apr 2, 2025

Enable Non-determinism of float operations in Miri and change std tests #138062

Open

Expose algebraic floating point intrinsics #136457

Are you sure you want to change the base?

Expose algebraic floating point intrinsics #136457

Conversation

calder commented Feb 3, 2025 • edited by tgross35 Loading

Problem

C++: 10us ✅

Nightly Rust: 10us ✅

Stable Rust: 84us ❌

Proposed Change

Alternatives Considered

References

rustbot commented Feb 3, 2025

rustbot commented Feb 3, 2025

calder commented Feb 3, 2025

RalfJung commented Feb 3, 2025 via email

RalfJung commented Feb 3, 2025 via email

calder commented Feb 3, 2025

RalfJung commented Feb 3, 2025

calder commented Feb 4, 2025 • edited Loading

Changes

tgross35 commented Feb 4, 2025 • edited Loading

rustbot commented Feb 5, 2025

Choose a reason for hiding this comment

tgross35 commented Feb 5, 2025 • edited Loading

calder commented Feb 5, 2025 • edited Loading

Per function examples

Central example

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

tgross35 commented Mar 11, 2025

bors commented Mar 11, 2025

This comment has been minimized.

bors commented Mar 11, 2025

tgross35 commented Mar 11, 2025

tgross35 commented Mar 12, 2025

bors commented Mar 12, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

calder Mar 29, 2025 • edited Loading

Choose a reason for hiding this comment

LorrensP-2158466 Mar 29, 2025 • edited Loading

Choose a reason for hiding this comment

calder Mar 29, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Mar 12, 2025

leonardo-m commented Mar 13, 2025 • edited Loading

calder commented Mar 29, 2025 • edited Loading

RalfJung commented Mar 29, 2025 via email

calder commented Mar 31, 2025

tgross35 commented Apr 2, 2025

bors commented Apr 2, 2025

rust-log-analyzer commented Apr 2, 2025

bors commented Apr 2, 2025

RalfJung commented Apr 3, 2025

calder commented Feb 3, 2025 •

edited by tgross35

Loading

calder commented Feb 4, 2025 •

edited

Loading

tgross35 commented Feb 4, 2025 •

edited

Loading

tgross35 commented Feb 5, 2025 •

edited

Loading

calder commented Feb 5, 2025 •

edited

Loading

calder Mar 29, 2025 •

edited

Loading

LorrensP-2158466 Mar 29, 2025 •

edited

Loading

calder Mar 29, 2025 •

edited

Loading

leonardo-m commented Mar 13, 2025 •

edited

Loading

calder commented Mar 29, 2025 •

edited

Loading