Using intrinsics instead of inline assembly in libm?

[valadaptive]

It seems that many architecture-specific implementations of libm functions use inline assembly instead of calling into intrinsics. This was apparently done in rust-lang/libm#459 to "avoid recursion issues". I assume this means the compiler lowering a math intrinsic to a libm function, which refers back to a math intrinsic, which is lowered to a libm function...

I'm worried that inline assembly could prevent a lot of optimizations. As far as I know, it's basically a black box as far as the compiler is concerned (and intentionally so).

What is currently blocking the libm crate from using intrinsics? libm#459 referred to recursion issues with cg_gcc and unspecified "problems with aarch64be". I don't really have any more context than that. I suspect some of it might have to do with the unstable core_float_math feature, whose methods now seem to call into compiler intrinsics. Do those compiler intrinsics still have the potential to be lowered to libm calls?

The "recursion" thing is a bit unfortunate, because it only applies when using the libm crate within Rust itself and allowing the compiler to emit libm calls. If you're using the libm crate for e.g. your no_std library, it doesn't apply, but you suffer a potential performance penalty anyway.

[tgross35]

I'm worried that inline assembly could prevent a lot of optimizations. As far as I know, it's basically a black box as far as the compiler is concerned (and intentionally so).

I guess the first question is, how has this shown up in practice? All of libm is effectively a blackbox, assembly shouldn't be any worse than anything else here (the optimizer has no idea these are math ops that could potentially be combined).

unspecified "problems with aarch64be". I don't really have any more context than that

I don't exactly remember but it was related to endian issues using vector intrinsics.

I suspect some of it might have to do with the unstable core_float_math feature, whose methods now seem to call into compiler intrinsics. Do those compiler intrinsics still have the potential to be lowered to libm calls?

Yes: on platforms where there is no hardware asm implementation or the backend doesn't support it, these intrinsics will turn into a libm call.

core_float_math will probably give you what you want here once stable.

[valadaptive]

I originally thought there were also scalar architecture-specific intrinsics exposed through core::arch, but it seems it only exposes vector intrinsics, which might not be as immediately useful. The situation is messy; there are several ways of performing "intrinsic" operations on floats (which I'm sure you know; just recapping them for clarity):

• Rust's forever-unstable core::intrinsics operations, which I believe map to target-agnostic LLVM intrinsics.
• Rust's core::arch intrinsics. I believe some of these map to target-specific LLVM intrinsics, and others map to target-agnostic LLVM intrinsics, and there's a push towards moving to the latter in order to better support alternative backends like Cranelift.
• Inline assembly. Notably, not the same as the corresponding LLVM target-specific intrinsic. For instance, LLVM knows about the semantics of @llvm.aarch64.frint32z.f32 but not an assembly block that calls frintz.

I guess the first question is, how has this shown up in practice? All of libm is effectively a blackbox, assembly shouldn't be any worse than anything else here (the optimizer has no idea these are math ops that could potentially be combined).

I don't have any benchmarks from application code, but the std implementations of round, floor, ceil, etc. compile down to LLVM intrinsics, and hence they can be 1) autovectorized, 2) constant-folded, and 3) fused.

Here's an example of all three optimizations on AArch64. I've used "round away from zero" as an example even though libm doesn't currently implement that in assembly, because "round with ties to even" doesn't seem to be fused. I'm going to go report that to LLVM.

In the "round single float to int" example, the assembly version compiles to an frinta (that's the rounding) followed by a fcvtzu (that's the conversion). The intrinsic version can be fused into a single fcvtau that does the rounding as part of the conversion.

In the "round four ints to floats" example, the assembly version compiles into four separate frinta+fcvtzus. The intrinsic version compiles to a vector frinta+fcvtzu. (Again, I think this should be further fuseable into a vector fcvtau; I'll have to see what's going on in LLVM).

Finally, in the "round constant to int" example, the assembly version actually performs the operations at runtime, while the intrinsic version can constant-fold everything away and becomes "return 3".

I do agree that core_float_math would solve my problems. I have no idea how it's progressing, or what the blockers are. The tracking issue has a "Steps/History" list, but all the checkboxes are unchecked, despite every linked issue being resolved and every linked PR being merged.

One question I have about core_float_math--and I'm not really sure where to ask this since you're not supposed to comment on tracking issues--why are div_euclid and rem_euclid included? I don't think they're implemented in any hardware, I believe they don't map to LLVM intrinsics, and per rust-lang/rust#107904, they require their own libm functions.

[tgross35]

I don't think we can provide what you want from within libm itself. As you noted, we can't actually ship the library with the unstable scalar intrinsic use, at least not in a way that benefits most users. We do use this in a few places behind a feature 1 2, but you may as well just use core_float_math at that point. And I really don't want to go back to the core::arch vector intrinsics since that was a nightmare figuring out which llvm/gcc/cranelift flavors would emit asm vs. lowering to a libcall that winds up circular.

I do agree that core_float_math would solve my problems. I have no idea how it's progressing, or what the blockers are. The tracking issue has a "Steps/History" list, but all the checkboxes are unchecked, despite every linked issue being resolved and every linked PR being merged.

I updated the issue. IMO the functions listed there are ready but the issue about our symbols replacing C versions isn't ideal. If you have any interest in pushing that forward, starting a topic on the T-libs zulip about rust-lang/rust#142119 would be rather helpful :)

One question I have about core_float_math--and I'm not really sure where to ask this since you're not supposed to comment on tracking issues--why are div_euclid and rem_euclid included? I don't think they're implemented in any hardware, I believe they don't map to LLVM intrinsics, and per rust-lang/rust#107904, they require their own libm functions.

Currently they are implemented in std so could theoretically move to core today, but I would like to move them to libm so they'll be in a similar boat as other libm functions (even though they aren't C spec). Reason being, the implementation needs fixing and thorough testing, and that's something better to live here. (There is an open PR in rust-lang/rust to make their implementations correctly rounded, but I requested the move here and the author hasn't had a chance to follow up.)

Also fyi what is currently in core_float_math isn't related to what does/doesn't have LLVM support, it's more based on how confident I am if the implementations from this crate happen to override the system implementations (first group at https://github.com/rust-lang/compiler-builtins/blob/eba1a3f3d2824739f07fe434624b0d2fee917d89/compiler-builtins/src/math/mod.rs).

[tgross35]

Something that might work for your usecase: try calling the functions directly via extern "C" { fn sqrtf(f32) -> f32 }. I believe LLVM detects these by name and will optimize them.

But as it stands, I don't think there is anything good we can do here so I am going to close this. If you need the optimizations now you can use std::arch in your crate, or try calling the functions directly.

Also as noted, the minimal subset for core_float_math is only blocked by some Zulip discussion regarding linking concerns, so help is welcome moving that forward.