wasm32 and aarch64 intrinsics for rint and rintf

[hanna-kruppe]

I didn't bother with x86 because SSE4.1-exclusive code paths are extra testing burden that's unlikely to benefit many people.

Closes #421

[hanna-kruppe]

For the record: there's a bunch of other libm functions that could be added here (sqrt, fma, probably floor/ceil/trunc as well) but I won't have time to work on that.

[tgross35]

Eventually I will probably attempt to script together the operations from https://github.com/kraj/musl/tree/eb4309b142bb7a8bdc839ef1faf18811b9ff31c8/src/math/aarch64 (and the other architectures), most of the rounding-related ops are covered there. But yeah, it isn't a priority for the time being.

[tgross35]

Thanks for jumping on this, the wasm changes look good to me. For aarch64, is there any reason not to just use assembly to get the non-vector version? For reference https://github.com/kraj/musl/blob/eb4309b142bb7a8bdc839ef1faf18811b9ff31c8/src/math/aarch64/rint.c

[tgross35]

Also just as a note, wasm checks the build but doesn't actually run any tests. I am not sure of a good way to do so, but am open to ideas if you have any.

[hanna-kruppe]

Thanks for jumping on this, the wasm changes look good to me. For aarch64, is there any reason not to just use assembly to get the non-vector version? For reference https://github.com/kraj/musl/blob/eb4309b142bb7a8bdc839ef1faf18811b9ff31c8/src/math/aarch64/rint.c

I don't think there's any fundamental obstacle (I though MSRV might be a problem but apparently not), I just don't fully trust myself to write that inline asm correctly and the only cost from using the vector variant is an extra vdup, which is very cheap. (I don't think the scalar vs. vector form makes any difference for the performance of rounding operation itself, at least as long as you stick to 64 bit vectors.)

$ cargo asm --target aarch64-unknown-linux-gnu --features unstable-intrinsics -p libm --lib rintf
.section .text.libm::math::rintf::rintf,"ax",@progbits
        .globl  libm::math::rintf::rintf
        .p2align        2
        .type   libm::math::rintf::rintf,@function
libm::math::rintf::rintf:
        .cfi_startproc
        dup v0.2s, v0.s[0]
        frintn v0.2s, v0.2s
        ret

Also just as a note, wasm checks the build but doesn't actually run any tests. I am not sure of a good way to do so, but am open to ideas if you have any.

You can run cargo test by installing wasmtime and setting target.<triple>.runner = "wasmtime" in the Cargo configuration (.cargo/config.toml or environment variable). I did this manually and it passed except for check_coverage::ensure_list_is_updated because it can't shell out. I don't know how this interacts with the other tests not run via cargo test.

[tgross35]

I don't think there's any fundamental obstacle (I though MSRV might be a problem but apparently not), I just don't fully trust myself to write that inline asm correctly and the only cost from using the vector variant is an extra vdup, which is very cheap. (I don't think the scalar vs. vector form makes any difference for the performance of rounding operation itself, at least as long as you stick to 64 bit vectors.)

For anything where MSRV would be a problem, I have just been gating things under unstable_intrinsics so at least anybody using this via std will benefit. There are some things that could be more fine grained, but I don't think it's worth adding more to possible feature combinations.

You can run cargo test by installing wasmtime and setting target.<triple>.runner = "wasmtime" in the Cargo configuration (.cargo/config.toml or environment variable). I did this manually and it passed except for check_coverage::ensure_list_is_updated because it can't shell out. I don't know how this interacts with the other tests not run via cargo test.

I do need to document this better but the only tests enabled by default are a handful of spotchecks, it needs the build-musl feature to build musl and compare against that, and/or test-multiprecision to test against MPFR. I have my doubts that either of those are likely work on wasm, unfortunately.

Thanks for the additions here!

[hanna-kruppe]

For what it's worth, wasi-libc uses a lightly modified musl for its libm and is used by Rust's wasm32-wasip1 target as part of std, so it might be relatively easy to compare against that. Though it might not be very useful for this specific change because they probably just end up using the same lowering for any functions that map directly to wasm instructions.