adds AArch64's {s,u,f}{min,max}{v,p} and ARM's {vmov}{n,l}

[gnzlbg]

• adds {s,u,f}{min,max}{v,p} AArch64 intrinsics
• adds {vmov}{n,l} ARM intrinsics

Closes #314 (the missing part there are portable shuffles, but I'll open a new issue just for that).

cc @hsivonen.

[alexcrichton]

Nice! r=me once CI is green

Before we go too hog wild with intrinsics though we may want to sort out the types first (aka add the dedicated types for arm/aarch64 and conversions from the portable ones)

[gnzlbg]

@alexcrichton ci was green for me, the failure is spurious "no input received for the last 10 minutes".

Before we go too hog wild with intrinsics though we may want to sort out the types first (aka add the dedicated types for arm/aarch64 and conversions from the portable ones)

I tried to choose intrinsics that exercise types that we don't have yet. These happened to be what @hsivonen needed and also have some variants using f16 that I wasn't able to implement. I'd implement a couple of the intrinsics that use "polynomial" vector types next, and the ones in issue #316 . Once we have a small corpus of intrinsics that exercise the weirdest things in ARM/AARCH64, I'll start adding the architecture specific vector types.

[alexcrichton]

Ok! If CI continues to be flaky we probably want to start splitting up test suites into separate crates to ease the burden on rustc

[gnzlbg]

Maybe we could use travis_wait somehow to increase the allowed time without output from 10 minutes to 20 minutes.

[alexcrichton]

Yeah I'd also be fine w/ that, but taking forever to build locally can also be a pain :(

[gnzlbg]

Could we:

• keep the tests in coresimd but behind a feature flag, e.g., ppsv_tests.
• add a third crate to the workspace that just includes the coresimd module (or coresimd), but always has this feature flag enabled

?

That way we can develop coresimd/stdsimd without compiling/running these tests, but still do run them as part of cargo test --all when executed on the root.

[alexcrichton]

Seems plausible to me!