intrinsics: Add a fallback for non-const libm float functions by tgross35 · Pull Request #150946 · rust-lang/rust

tgross35 · 2026-01-10T23:57:33Z

A number of float operations from libm have intrinsics for optimization, but it is also okay to just call the libm functions directly. Add a fallback for these cases, including converting to/from another float size where needed, so the backends don't need to override these.

r? @RalfJung

rustbot · 2026-01-10T23:57:36Z

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

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

tgross35 · 2026-01-10T23:59:40Z

 #[rustc_intrinsic_const_stable_indirect]
 #[rustc_intrinsic]
 #[rustc_nounwind]
 pub const fn fmaf128(a: f128, b: f128, c: f128) -> f128;


Is there a way to provide a non-const fallback for const intrinsics? In cases where CTFE definitely has to hook it rather than using the fallback, like here.

Not the worst thing if not.

I don't think there is -- please file an issue.

Opened #150961

tgross35 · 2026-01-11T03:15:32Z

error: `compiler_builtins` cannot call functions through upstream monomorphizations; encountered invalid call from `core::intrinsics::sqrtf64` to `core::num::libm::sqrt`
    --> library/core/src/intrinsics/mod.rs:1047:1
     |
1047 | pub fn sqrtf64(x: f64) -> f64 {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Huh - so #[inline] doesn't make a difference here. The body itself shouldn't be a problem since it's calling an extern function. @saethlin any idea what is going on here?

saethlin · 2026-01-11T03:31:12Z

At a glance, your reasoning is completely backwards. The fallback body for sqrtf64 is being monomorphized, which is disallowed because it calls a libm function that is upstream.

tgross35 · 2026-01-11T04:50:53Z

It shouldn't be; the libm module in core is only bindings to libm, the function call is just an extern.

RalfJung · 2026-01-11T10:52:23Z

The changes LGTM. However I can't actually check whether what you say about what is available where is correct -- you would be the person I ask about things like that. ;)
Is there anyone else who knows those details of libm and our compiler-builtins? If not, I'm also fine with approving this based on your judgment.

tgross35 · 2026-01-11T11:28:41Z

https://github.com/rust-lang/compiler-builtins/blob/65624df7f55db9b7b494fbe3aa9dcea0a743eea4/compiler-builtins/src/math/mod.rs is what controls what we sometimes/always provide, so the module root symbols and likely_available match that. Then the remaining maybe_available symbols are part of glibc (e.g. https://github.com/bminor/glibc/blob/e539a269990dac3ff4d2432c0eb6966a5ee4f274/sysdeps/unix/sysv/linux/i386/libm.abilist#L590), but not too much else.

saethlin · 2026-01-11T14:06:04Z

It shouldn't be; the libm module in core is only bindings to libm, the function call is just an extern.

Yes, that's the problem. The body for the function is not available in the crate compiler-builtins when compiling compiler-builtins.

Remember the the rule is to ban linkage against other crates and the point of these extern declarations is to use linkage.

tgross35 · 2026-02-13T15:00:44Z

It shouldn't be; the libm module in core is only bindings to libm, the function call is just an extern.

Yes, that's the problem. The body for the function is not available in the crate compiler-builtins when compiling compiler-builtins.

Remember the the rule is to ban linkage against other crates and the point of these extern declarations is to use linkage.

Forgot to follow up here. In this case it there isn't anything technically incorrect right, and instead it's a limitation of the knowledge the compiler has to emit that error? Because c-b itself provides the sqrt symbol so it will be available to link. I can drop the sqrt fallbacks for now since the status quo is fine anyway, but it seems like maybe the ideal solution would be something like an #[allow_compiler_builtins_link] attribute on the extern "C" block?

It probably goes without saying but libm isn't calling the sqrt intrinsic in fn sqrt itself, it's used elsewhere so we get the asm lowering if available.

saethlin · 2026-02-13T22:01:08Z

Oh I see, thanks for clarifying. I think this is actually a limitation of the check logic itself. The problem is that you have an item defined in an upstream crate, which is not should_codegen_locally... except that it is codegenned in the local crate in this one case because of the linkage relationship.

So the missing check is whether the Instance inside is_call_from_compiler_builtins_to_upstream_monomorphization is actually an extern declaration of a symbol name that is in the current crate's exported_symbols. I think this is a feasible check for you to write if you want. ~~I'm a bit busy for a bit or I'd try to slap it together~~. @bjorn3 since this is fiddly linkage stuff.

saethlin · 2026-02-14T19:36:38Z

I threw this together to convince myself that this can work, and it seems to work.

diff --git a/compiler/rustc_codegen_ssa/src/base.rs b/compiler/rustc_codegen_ssa/src/base.rs
index c8aa7c04585..3fc0411d2be 100644
--- a/compiler/rustc_codegen_ssa/src/base.rs
+++ b/compiler/rustc_codegen_ssa/src/base.rs
@@ -867,6 +867,10 @@ pub fn codegen_crate<B: ExtraBackendMethods>(
 /// unlinkable calls.
 ///
 /// Note that calls to LLVM intrinsics are uniquely okay because they won't make it to the linker.
+/// Note also that calls to foreign items that are actually exported by the local crate are also
+/// okay. This situation arises because compiler-builtins calls functions in core that are #[inline]
+/// wrappers for extern "C" declarations in core, which resolve to a symbol exported by
+/// compiler-builtins.
 pub fn is_call_from_compiler_builtins_to_upstream_monomorphization<'tcx>(
     tcx: TyCtxt<'tcx>,
     instance: Instance<'tcx>,
@@ -879,11 +883,19 @@ fn is_llvm_intrinsic(tcx: TyCtxt<'_>, def_id: DefId) -> bool {
         }
     }
 
+    fn is_extern_call_to_local_crate<'tcx>(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) -> bool {
+        tcx.is_foreign_item(instance.def_id())
+            && tcx.exported_non_generic_symbols(LOCAL_CRATE).iter().any(|(sym, _info)| {
+                sym.symbol_name_for_local_instance(tcx) == tcx.symbol_name(instance)
+            })
+    }
+
     let def_id = instance.def_id();
     !def_id.is_local()
         && tcx.is_compiler_builtins(LOCAL_CRATE)
         && !is_llvm_intrinsic(tcx, def_id)
         && !tcx.should_codegen_locally(instance)
+        && !is_extern_call_to_local_crate(tcx, instance)
 }
 
 impl CrateInfo {

The linear search of all exported non-generic symbols seems bad. It's only done a handful of times so it doesn't have a visible impact on compile time of compiler-builtins... yet.

RalfJung · 2026-02-21T16:27:58Z

@rustbot author

rustbot · 2026-02-21T16:28:02Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

rust-bors · 2026-07-08T20:02:04Z

This pull request was unapproved.

This PR was contained in a rollup (#158958), which was unapproved.

View changes since this unapproval

intrinsics: Add a fallback for non-const libm float functions try-job: i686-msvc-1

folkertdev · 2026-07-08T20:53:52Z

I actually suspect this is an interaction with #158927 (part of that same rollup), so the bors job here will likely be fine.

But apparently we should go via f64 in msvc.

rust-bors · 2026-07-08T21:35:13Z

⚠️ A new commit a6f8d095786c2e5b523ee1a6429411b9a9ec6fe4 was pushed.

This PR was contained in a rollup (#158958), which was closed.

RalfJung · 2026-07-08T21:38:29Z

-    libm::likely_available::sinf(x)
+    cfg_select! {
+        target_env = "msvc" => sinf64(x as f64) as f32,
+        _ => libm::likely_available::sinf(x),


Looks like we should remove the sinf import on Windows as well to avoid accidentally calling it? (Same for the others)

View changes since the review

Well they are already marked as likely available, but I can just cfg them out on x86 msvc?

Seems wrong to call them likely available if we know them to be unavailable. ;)

folkertdev · 2026-07-08T22:00:02Z

@bors try jobs=i686-msvc-1,x86_64-msvc-1,aarch64-msvc-1,x86_64-mingw-1

intrinsics: Add a fallback for non-const libm float functions try-job: i686-msvc-1 try-job: x86_64-msvc-1 try-job: aarch64-msvc-1 try-job: x86_64-mingw-1

the 32-bit symbols are not available on msvc

folkertdev · 2026-07-08T22:50:44Z

@bors try jobs=i686-msvc-1,x86_64-msvc-1,aarch64-msvc-1,x86_64-mingw-1

intrinsics: Add a fallback for non-const libm float functions try-job: i686-msvc-1 try-job: x86_64-msvc-1 try-job: aarch64-msvc-1 try-job: x86_64-mingw-1

rust-bors · 2026-07-09T02:03:47Z

☀️ Try build successful (CI)
Build commit: b0486e8 (b0486e8097bf7dbf95d5f24371c08c38f3985623)
Base parent: 7ef36ed (7ef36edc23ac10760eb9f097d32edbab2e1e8928)

we know that the symbols are not available there

folkertdev · 2026-07-09T09:43:24Z

+    cfg_select! {
+        all(target_env = "msvc", target_arch = "x86") => {
+            /* these symbols are not available on x86 msvc */
+        }
+        _ => {
+            #[allow(dead_code)]


The cfg_select is to work around

tidy [pal (library)]: library/core/src/num/imp/libm.rs:82: platform-specific cfg: cfg(not(all(target_env = "msvc", target_arch = "x86"))) tidy [pal (library)]: FAIL

but it gives a good place for a comment so it's probably fine this way.

View changes since the review

Anyhow, there might be some nicer refactor that can be done, but this PR means we can drop one of the cranelift patch files, so I think we can defer that additional work.

RalfJung · 2026-07-09T09:47:48Z

r=RalfJung,saethlin when CI is happy.
@bors rollup=iffy

folkertdev · 2026-07-09T09:53:07Z

better safe than sorry etc

@bors try jobs=i686-msvc-1,x86_64-msvc-1,aarch64-msvc-1,x86_64-mingw-1

rust-bors · 2026-07-09T09:53:14Z

⌛ Trying commit e732dd1 with merge 5d627ac…

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

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

intrinsics: Add a fallback for non-const libm float functions try-job: i686-msvc-1 try-job: x86_64-msvc-1 try-job: aarch64-msvc-1 try-job: x86_64-mingw-1

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 Jan 10, 2026

rustbot assigned RalfJung Jan 10, 2026

tgross35 commented Jan 10, 2026

View reviewed changes

tgross35 mentioned this pull request Jan 11, 2026

Math operations for f16 incorrectly implemented rust-lang/rustc_codegen_cranelift#1622

Open

This comment has been minimized.

Sign in to view

tgross35 force-pushed the float-intrinsic-fallback branch from d533ef5 to 90b9d6a Compare January 11, 2026 01:59

This comment has been minimized.

Sign in to view

tgross35 mentioned this pull request Jan 11, 2026

Intrinsics should allow a non-const fallback body if hooked for CTFE #150961

Open

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 21, 2026

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 21, 2026

bjorn3 mentioned this pull request Mar 6, 2026

Cranelift patch files are painful to maintain #153488

Open

tgross35 mentioned this pull request Mar 14, 2026

Merge fabsf16/32/64/128 into fabs::<F> #153834

Merged

This was referenced Apr 16, 2026

Missing cfg(target_has_reliable_f16_math) check for f16 tests rust-lang/portable-simd#519

Closed

Make unary float intrinsics generic #153934

Open

folkertdev force-pushed the float-intrinsic-fallback branch from 90b9d6a to 176fd06 Compare June 23, 2026 21:17

This comment has been minimized.

Sign in to view

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 8, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jul 8, 2026

Auto merge of #150946 - tgross35:float-intrinsic-fallback, r=<try>

80ccb8a

intrinsics: Add a fallback for non-const libm float functions try-job: i686-msvc-1

use f32 intrinsic directly in fallback for f16 intrinsic

a5ee71c

RalfJung reviewed Jul 8, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

folkertdev force-pushed the float-intrinsic-fallback branch 2 times, most recently from 8759054 to 109180e Compare July 8, 2026 21:56

This comment has been minimized.

Sign in to view

on msvc, make f32 fallback to f64

58c2c07

the 32-bit symbols are not available on msvc

folkertdev force-pushed the float-intrinsic-fallback branch from 109180e to 58c2c07 Compare July 8, 2026 22:49

This comment has been minimized.

Sign in to view

configure out 32-bit transcendental functions on x86 msvc

e732dd1

we know that the symbols are not available there

folkertdev reviewed Jul 9, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

tgross35 commented Jan 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 10, 2026

Uh oh!

tgross35 Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

tgross35 Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

tgross35 commented Jan 11, 2026

Uh oh!

saethlin commented Jan 11, 2026

Uh oh!

tgross35 commented Jan 11, 2026

Uh oh!

RalfJung commented Jan 11, 2026

Uh oh!

tgross35 commented Jan 11, 2026

Uh oh!

saethlin commented Jan 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

tgross35 commented Feb 13, 2026

Uh oh!

saethlin commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

saethlin commented Feb 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented Feb 21, 2026

Uh oh!

rustbot commented Feb 21, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jul 8, 2026

Uh oh!

This comment has been minimized.

folkertdev commented Jul 8, 2026

Uh oh!

rust-bors Bot commented Jul 8, 2026

Uh oh!

RalfJung Jul 8, 2026 • 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!

folkertdev Jul 9, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Jul 9, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

folkertdev commented Jul 8, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

folkertdev commented Jul 8, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Jul 9, 2026

Uh oh!

folkertdev Jul 9, 2026 • 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!

folkertdev Jul 9, 2026

tgross35 commented Jan 10, 2026 •

edited by rustbot

Loading

saethlin commented Jan 11, 2026 •

edited

Loading

saethlin commented Feb 13, 2026 •

edited

Loading

saethlin commented Feb 14, 2026 •

edited

Loading

RalfJung Jul 8, 2026 •

edited by rustbot

Loading

folkertdev Jul 9, 2026 •

edited by rustbot

Loading

RalfJung commented Jul 9, 2026 •

edited

Loading

rust-bors Bot commented Jul 9, 2026 •

edited

Loading