use correct LLVM intrinsic for min/max on floats by RalfJung · Pull Request #153343 · rust-lang/rust

RalfJung · 2026-03-03T11:40:46Z

The Rust minnum/maxnum intrinsics are documented to return the other argument when one input is an SNaN. However, the LLVM lowering we currently choose for them does not match those semantics: we lower them to minnum/maxnum, which (since llvm/llvm-project#172012) is documented to non-deterministically return the other argument or NaN when one input is an SNaN.

LLVM does have an intrinsic with the intended semantics: minimumnum/maximumnum. Let's use that instead. We can set the nsz flag since we treat signed zero ordering as non-deterministic.

Also rename the intrinsics to follow the IEEE 2019 naming, since that is mostly (and in particular, as far as NaN are concerned) now what we do. Also, minimum_number and minimum are less easy to mix up than minnum and minimum.

r? @nikic
Cc @tgross35
Fixes #149537

rustbot · 2026-03-03T11:40:50Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

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

cc @rust-lang/miri, @oli-obk, @lcnr

Some changes occurred to the CTFE machinery

cc @oli-obk, @lcnr

RalfJung · 2026-03-03T11:41:14Z

compiler/rustc_codegen_llvm/src/intrinsic.rs

+                );
+                // `nsz` in minimumnum/maximumnum is special: its only effect is to make signed-zero
+                // ordering non-deterministic.
+                unsafe { llvm::LLVMRustSetNoSignedZeros(call) };


I have no idea if the way I wired up nsz is correct.^^

RalfJung · 2026-03-03T11:41:33Z

compiler/rustc_codegen_cranelift/src/intrinsics/mod.rs

            let b = b.load_scalar(fx);

+            // FIXME: make sure this has the intended behavior for SNaN
+            // (returning the other argument).


@bjorn3 does cranelift have intrinsics that have the intended guarantee re: SNaN?
Or should we use the fallback impl here?

compiler/rustc_codegen_gcc/src/intrinsic/mod.rs

nikic

r=me once the questions for other backends are answered.

View changes since this review

nikic · 2026-03-03T12:02:48Z

compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp

+  if (auto I = dyn_cast<Instruction>(unwrap<Value>(V))) {
+    I->setHasNoSignedZeros(true);
+  }
+}


The C bindings have a native LLVMSetFastMathFlags(), we should probably switch to that. But I guess we should do that consistently for the existing LLVMRustSetAlgebraicMath/LLVMRustSetAllowReassoc/LLVMRustSetFastMath as well, so I don't particularly mind this in the meantime.

Yeah I don't know why we have a separate wrapper for each flag configuration here, but I figured I'd follow the existing pattern.

RalfJung · 2026-03-03T12:44:57Z

There are some odd things happening in CI

2026-03-03T12:31:32.4740066Z rustc-LLVM ERROR: Cannot select: 0xff67d41c22a0: f128 = fcanonicalize nsz 0xff67d41c2a10
2026-03-03T12:31:32.4740629Z   0xff67d41c2a10: f128 = AArch64ISD::CSEL 0xff67d41c5660, 0xff67d41c52e0, Constant:i32<11>, 0xff67d41c2930:1

Why did fcanonicalize end up with nsz? That was meant just for minimumnum.
And also it seems like f128 minimumnum is just broken on aarch64?

RalfJung · 2026-03-03T12:47:11Z

That was on the aarch64-gnu-llvm-20-1 runner. Maybe we have to fall back to minnum/maxnum for old LLVM versions?

library/core/src/intrinsics/mod.rs

nikic · 2026-03-03T13:23:58Z

That was on the aarch64-gnu-llvm-20-1 runner. Maybe we have to fall back to minnum/maxnum for old LLVM versions?

Ah yes, that's a good point. I believe minimumnum used to have some selection failures that were only fixed in LLVM 22.

RalfJung · 2026-03-03T13:46:04Z

I guess that makes sense, the test fails on old LLVM where we (have to) use the wrong intrinsic.

RalfJung · 2026-03-03T13:53:26Z

@bors try jobs=x86_64-gnu,aarch64-gnu

rename min/maxnum intrinsics to min/maximum_number and fix their LLVM lowering try-job: x86_64-gnu try-job: aarch64-gnu

RalfJung · 2026-03-03T15:27:27Z

This is very strange, I tested the fallback implementation locally and it passes. Why does it fail on the aarch runner?

And it's also a very strange return value. The inputs are from_bits(0x7fbfffff) and -9.0 and the output is from_bits(0x7fffffff)?!?

rust-bors · 2026-03-03T16:16:19Z

☀️ Try build successful (CI)
Build commit: 5fc4d3f (5fc4d3f9142818f2f2b292605ba61c2b9b55f112, parent: 1b7d722f429f09c87b08b757d89c689c6cf7f6e7)

RalfJung · 2026-03-03T16:27:48Z

now with the commit that always forces the fallback impl to be used
@bors try jobs=x86_64-gnu,aarch64-gnu,x86_64-gnu-gcc

rename min/maxnum intrinsics to min/maximum_number and fix their LLVM lowering try-job: x86_64-gnu try-job: aarch64-gnu try-job: x86_64-gnu-gcc

RalfJung · 2026-03-03T16:32:56Z

Seems like LLVM 20 straight-up miscompiles code like this

fn minimum_num(x: f32, y: f32) -> f32 {
    if x.is_nan() || y >= x {
        y
    } else {
        // Either y < x or y is a NaN.
        x
    }
}

const SNAN: f32 = f32::from_bits(f32::NAN.to_bits() - 1);

fn main() {
    dbg!(minimum_num(-9.0, std::hint::black_box(SNAN)));
}

I tried this on an aarch64 dev desktop: with Rust 1.87, an optimized build prints NaN, with latest stable Rust, it prints -9.0.

How do we handle library tests that trigger miscompilations on old LLVM versions...? We could just remove the black_box, but -- it'd be a shame to reduce test coverage on newer LLVM just because we also still test old LLVM.

Are we anywhere close to dropping LLVM 20? :D

RalfJung · 2026-03-03T20:26:02Z

The issue is that the fallback impl miscompiles on aarch64 with LLVM 20.^^ And the intrinsic crashes LLVM.

tgross35 · 2026-03-03T20:30:20Z

Ah sorry, I just came to the same realization. I've come across that before and unfortunately there wasn't a good way #t-infra/bootstrap > LLVM version in std so I think what you have is about the best option for now.

Honestly I would love to have a very internal cfg for backend name and version so we don't need to jump through these kind of hoops when similar situations pop up.

RalfJung · 2026-03-03T22:36:31Z

The job aarch64-gnu failed! Check out the build log: (web) (plain enhanced) (plain)
Click to see the possible cause of the failure (guessed by this bot)

This is very strange, why does the fallback impl get miscompiled with the in-tree LLVM?

RalfJung · 2026-03-04T07:30:39Z

Ah... yeah this would not work with -Zmiri-force-intrinsic-fallback. Argh.

rustbot · 2026-03-04T07:49:06Z

The Miri subtree was changed

cc @rust-lang/miri

RalfJung · 2026-03-04T08:13:23Z

It seems like indeed the miscompilation still occurs with the in-tree LLVM on aarch64 -- just not in my minimal example. I have no idea how to minimize this...

tgross35 · 2026-03-04T08:27:35Z

The job aarch64-gnu failed! Check out the build log: (web) (plain enhanced) (plain)
Click to see the possible cause of the failure (guessed by this bot)

This is very strange, why does the fallback impl get miscompiled with the in-tree LLVM?

Is it using the fallback implementation? I'd think in-tree is using the intrinsics since we're on 22.x. Maybe worth another test in tests/codegen-llvm/float to verify?

RalfJung · 2026-03-04T08:55:11Z

For that try build I added a hack in the backend to always use the fallback impl. That's also what I did to reproduce this on the dev desktop.

nikic · 2026-03-04T09:01:38Z

The AArch64 miscompile is llvm/llvm-project#176624. And yes, that one still exists on current main. (The intrinsics are fine.)

RalfJung · 2026-03-04T09:32:22Z

@nikic thanks a ton, you just saved me a lot of digging. :)

RalfJung · 2026-03-04T09:36:40Z

So, for this PR -- I guess the best we can do is use the intrinsic on LLVM22+ and the fallback impl for older LLVM, even if the fallback impl sometimes gives the wrong results on aarch64 (for SNaN inputs). We already sometimes give wrong results on aarch64 before this PR so that's not even a regression.

Or can we get away with using the intrinsic on LLVM 21 already?

library/coretests/tests/floats/mod.rs

… lowering

RalfJung · 2026-03-05T15:35:15Z

@bors try jobs=x86_64-gnu,aarch64-gnu

use correct LLVM intrinsic for min/max on floats try-job: x86_64-gnu try-job: aarch64-gnu

rust-bors · 2026-03-05T17:21:54Z

💔 Test for e9e3af0 failed: CI

RalfJung · 2026-03-05T21:12:18Z

"The operation was canceled"?

@bors try jobs=x86_64-gnu,aarch64-gnu

rust-bors · 2026-03-05T21:12:23Z

⌛ Trying commit 1e50a40 with merge e5a358e…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/22736973220

use correct LLVM intrinsic for min/max on floats try-job: x86_64-gnu try-job: aarch64-gnu

rustbot assigned nikic Mar 3, 2026

RalfJung commented Mar 3, 2026

View reviewed changes

compiler/rustc_codegen_gcc/src/intrinsic/mod.rs Outdated Show resolved Hide resolved

nikic reviewed Mar 3, 2026

View reviewed changes

RalfJung force-pushed the min-max-fix branch from 685c6e9 to 0e8b777 Compare March 3, 2026 12:50

RalfJung commented Mar 3, 2026

View reviewed changes

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

This comment has been minimized.

Sign in to view

RalfJung force-pushed the min-max-fix branch from 0e8b777 to 3eb2e56 Compare March 3, 2026 13:52

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Mar 3, 2026

Auto merge of #153343 - RalfJung:min-max-fix, r=<try>

5fc4d3f

rename min/maxnum intrinsics to min/maximum_number and fix their LLVM lowering try-job: x86_64-gnu try-job: aarch64-gnu

This comment has been minimized.

Sign in to view

RalfJung force-pushed the min-max-fix branch from 1b06b99 to 5b7ba5f Compare March 3, 2026 16:08

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Mar 3, 2026

Auto merge of #153343 - RalfJung:min-max-fix, r=<try>

9c8cd8b

rename min/maxnum intrinsics to min/maximum_number and fix their LLVM lowering try-job: x86_64-gnu try-job: aarch64-gnu try-job: x86_64-gnu-gcc

RalfJung force-pushed the min-max-fix branch 2 times, most recently from 8ce6631 to 977fa0b Compare March 3, 2026 22:46

This comment has been minimized.

Sign in to view

RalfJung force-pushed the min-max-fix branch from 977fa0b to 1ff1a00 Compare March 4, 2026 07:49

RalfJung force-pushed the min-max-fix branch from 1ff1a00 to 87aca5f Compare March 4, 2026 09:39

This was referenced Mar 4, 2026

What are the intended semantics for simd_fmin/fmax and simd_reduce_min/max vs signaling NaN? #153395

Open

fmax optimization on aarch64 unexpectedly working for signaling NaN #151286

Open

RalfJung changed the title ~~rename min/maxnum intrinsics to min/maximum_number and fix their LLVM lowering~~ use correct LLVM intrinsic for min/max on floats Mar 4, 2026

nikic reviewed Mar 5, 2026

View reviewed changes

library/coretests/tests/floats/mod.rs Outdated Show resolved Hide resolved

RalfJung force-pushed the min-max-fix branch from 87aca5f to 1504221 Compare March 5, 2026 15:19

rename min/maxnum intrinsics to min/maximum_number and fix their LLVM…

1e50a40

… lowering

RalfJung force-pushed the min-max-fix branch from 1504221 to 1e50a40 Compare March 5, 2026 15:34

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Mar 5, 2026

Auto merge of #153343 - RalfJung:min-max-fix, r=<try>

e9e3af0

use correct LLVM intrinsic for min/max on floats try-job: x86_64-gnu try-job: aarch64-gnu

rust-bors bot pushed a commit that referenced this pull request Mar 5, 2026

Auto merge of #153343 - RalfJung:min-max-fix, r=<try>

e5a358e

use correct LLVM intrinsic for min/max on floats try-job: x86_64-gnu try-job: aarch64-gnu

Uh oh!

Conversation

RalfJung commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 3, 2026

Uh oh!

RalfJung Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nikic left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikic Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Mar 3, 2026

Uh oh!

RalfJung commented Mar 3, 2026

Uh oh!

Uh oh!

nikic commented Mar 3, 2026

Uh oh!

This comment has been minimized.

RalfJung commented Mar 3, 2026

Uh oh!

RalfJung commented Mar 3, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

RalfJung commented Mar 3, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Mar 3, 2026

Uh oh!

RalfJung commented Mar 3, 2026

Uh oh!

This comment has been minimized.

RalfJung commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented Mar 3, 2026

Uh oh!

tgross35 commented Mar 3, 2026

Uh oh!

RalfJung commented Mar 3, 2026

Uh oh!

This comment has been minimized.

RalfJung commented Mar 4, 2026

Uh oh!

rustbot commented Mar 4, 2026

Uh oh!

RalfJung commented Mar 4, 2026

Uh oh!

tgross35 commented Mar 4, 2026

Uh oh!

RalfJung commented Mar 4, 2026 via email

Uh oh!

nikic commented Mar 4, 2026

Uh oh!

RalfJung commented Mar 4, 2026

Uh oh!

RalfJung commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

RalfJung commented Mar 5, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Mar 5, 2026

Uh oh!

RalfJung commented Mar 3, 2026 •

edited

Loading

RalfJung Mar 3, 2026 •

edited

Loading

nikic left a comment •

edited by rustbot

Loading

RalfJung commented Mar 3, 2026 •

edited

Loading

RalfJung commented Mar 4, 2026 •

edited

Loading

rust-bors bot commented Mar 5, 2026 •

edited

Loading