Add assembly version of simple operations on aarch64

[tgross35]

Replace core::arch versions of the following with handwritten
assembly, which avoids recursion issues (cg_gcc using rint as a
fallback) as well as problems with aarch64be.

• rint
• rintf

Additionally, add assembly versions of the following:

• fma
• fmaf
• sqrt
• sqrtf

If the fp16 target feature is available, which implies neon, also
include the following:

• rintf16
• sqrtf16

sqrt is added to match the implementation for x86. fma is included
since it is used by many other routines.

There are a handful of other operations that have assembly
implementations. They are omitted here because we should have basic
float math routines available in core in the near future, which will
allow us to defer to LLVM for assembly lowering rather than implementing
these ourselves.

[tgross35]

@Amanieu would you mind double checking the assembly in src/math/arch/aarch64.rs? I am unsure whether preserves_flags should be set, I believe some of these operations may set flags based on the exception control register.

Cc @hanna-kruppe, while I was working on the others I also replaced the rint vector implementation.

[Amanieu]

For fmin/fmax you can use the fminnm/fmaxnm instructions which map to IEEE minNum/maxNum.

Also you will want to make these impls conditional on the fp target feature so that these are not used on soft-float targets.

However I'm then questioning how useful these are on hard-float targets: the standard library will invoke the LLVM intrinsic which will lower to the instruction, so the libm function will never be called. If this is only for compiler-builtins then it might be better to keep libm soft-float only.

However I am questioning

[Amanieu]

You want either:

• frintn to use round-to-nearest, ties to even.
• frinti to use the current rounding mode in fpcr.

[tgross35]

Thanks, rint should follow the rounding mode so I guess frinti is more correct to the C spec. Updated.

[tgross35]

Actually rint may optionally raise FE_INEXACT so I think frintx might have worked? Irrelevant for Rust in any case.

[hanna-kruppe]

If this is only for Rust and should never be picked up by C code, I’d argue for frintn. Rust does not support other rounding modes nor FP exceptions, and if someone ignores that and e.g. causes UB by configuring a non-default rounding mode then it’s better if they get unexpected results immediately than if it appears to work in simple cases.

[hanna-kruppe]

(If the symbols from libm-via-compiler_builtins do get picked up by C code compiled with FENV_ACCESS enabled, then there’s a much bigger problem because none of the Rust code in libm can support that.)

[hanna-kruppe]

However I'm then questioning how useful these are on hard-float targets: the standard library will invoke the LLVM intrinsic which will lower to the instruction, so the libm function will never be called. If this is only for compiler-builtins then it might be better to keep libm soft-float only.

At least some of these are used internally within libm by functions that still need to exist on hard-float targets. For example, floor is used by rem_pio2_large which is needed by many trigonometric functions.

(Plus the benefits for non-compiler-builtins consumers, who are not the main point of this crate but it’s still nice-to-have.)

[Amanieu]

For the operations that are used internally, the ideal end state that we want is for libm to use the float methods from core, which will then be lowered by LLVM to the appropriate instructions.

[hanna-kruppe]

Is there any harm in taking the improvement now and revisiting once those methods are actually available in core?

[tgross35]

My only motivation here is fma - some of the incoming CORE-math routines rely on it, I wanted to have a more accurate icount comparison without soft fma before mul_add is available in core. Nothing else is important, I just included the other simple ops since they are reasonably trivial.

[tgross35]

I dropped most of this change but kept:

• rint because the SIMD calls are preexisting, this is causing issues with cg_gcc
• sqrt and fma because they are used for a lot of other routines. This is mostly for direct users of libm until math in core is stable.