Stabilize existing neon instrinsics

[jrmuizel]

Having to use nightly for NEON is pain. Is there any reason we can stabilize the intrinsics that we already have implemented? If not, what's needed to do this?

[Lokathor]

opened a zulip topic to get this a little more attention: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/When.20can.20we.20do.20a.20partial.20stabilization.20of.20Neon.20intrinsics.3F

[Amanieu]

One thing that would make me more comfortable with partial stabilization is a test that checks that the stdarch intrinsics behave identically to the C versions with random inputs.

[jrmuizel]

Is there some infrastructure for doing that on x86 that can be reused?

…

On Mon, Apr 19, 2021, 2:25 AM Amanieu ***@***.***> wrote: One thing that would make me more comfortable with partial stabilization is a test that checks that the stdarch intrinsics behave identically to the C versions with random inputs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1125 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRG3ME3BQDRPASUXL5QHTTJPEGPANCNFSM43E2HMMQ> .

[Amanieu]

No. Ideally we would want a solution that can auto-generate tests for both ARM and x86.

[SparrowLii]

One thing that would make me more comfortable with partial stabilization is a test that checks that the stdarch intrinsics behave identically to the C versions with random inputs.

How should we get the behavior of these instructions in Clang? I think this requires disassembling the corresponding Clang program and putting the result into the tests. Could it be a way to get them from llvm's document?

[JamieCunliffe]

As mentioned on zulip, we had been looking at alternative ways to generate the intrinsics, one of the things we did could be repurposed to compare c and rust intrinsics. What we did was basically generate C programs and compile them to LLVM IR so it wouldn't be much more to actually run them to get the results.

I can change the input source to be the spreadsheet that is currently tracking intrinsics, that should make it fairly generic.

My initial thoughts were this would be a binary that was run that would generate some C and rust that calls the intrinsic with the same random inputs and then print the results of the intrinsic call, we can then diff the two programs outputs and see if anything differs. If that's the case I should hopefully be able to share something soon.

[Amanieu]

My initial thoughts were this would be a binary that was run that would generate some C and rust that calls the intrinsic with the same random inputs and then print the results of the intrinsic call, we can then diff the two programs outputs and see if anything differs. If that's the case I should hopefully be able to share something soon.

Yes that's exactly what I had in mind.

[fzyzcjy]

Hi, is there any updates? NEON is very much needed with Rust! Thanks.

[bartelsielski]

#1266 stabilized the neon intrinsics for aarch64. Are there plans to also stabilize neon on 32-bit arm?

[Amanieu]

There are many intrinsics that are still buggy or missing on ARM: https://github.com/rust-lang/stdarch/blob/master/crates/intrinsic-test/missing_arm.txt