Add SVE2 BitPerm intrinsics (BDEP, BEXT, BGRP)

[ADunfield]

Summary

Add Rust bindings for the three SVE2 bit-permutation instructions (FEAT_SVE_BitPerm):

• BDEP (svbdep_u{8,16,32,64}) — Bit Deposit: scatter consecutive low bits to mask-selected positions. SVE2 equivalent of x86 BMI2 PDEP.
• BEXT (svbext_u{8,16,32,64}) — Bit Extract: gather bits from mask-selected positions into consecutive low bits. SVE2 equivalent of x86 BMI2 PEXT.
• BGRP (svbgrp_u{8,16,32,64}) — Bit Group: partition bits into two groups by mask (selected bits packed low, unselected packed high). No x86 equivalent.

12 intrinsics total, all gated by #[target_feature(enable = "sve2-bitperm")].

Implementation

• SVE types (svuint8_t through svint64_t): defined using #[rustc_scalable_vector(N)] from rustc_scalable_vector(N) rust#143924
• LLVM intrinsics: llvm.aarch64.sve.{bdep,bext,bgrp}.x.nxv{N}i{M} — verified correct via Clang assembly output on Graviton 4
• Feature gates: stdarch_aarch64_sve (types), stdarch_aarch64_sve2_bitperm (intrinsics)
• Scalar _n_ variants deferred until base SVE1 intrinsics (svdup_n_u*) land

Testing

• 13 scalar reference tests verifying BDEP/BEXT/BGRP correctness (exhaustive u8 roundtrip, property-based inverse tests)
• LLVM intrinsic names validated via Clang -emit-llvm on aarch64
• Assembly output confirmed (bdep z0.d, z0.d, z1.d etc.) via Clang -O2 on AWS Graviton 4 (c8g, Neoverse V2)
• cargo check --target aarch64-unknown-linux-gnu passes on nightly 1.96.0

Dependencies

• rustc_scalable_vector(N) rust#143924 — #[rustc_scalable_vector(N)] (merged)
• Tracking Issue for Scalable Vectors (stdarch_aarch64_sve) rust#145052 — scalable vectors tracking issue
• Coordinates with SVE types and intrinsics #1509 (SVE types and intrinsics) — this PR adds SVE2 BitPerm on top of minimal SVE type definitions

Hardware tested on

• AWS Graviton 4 (c8g.medium, Neoverse V2) — /proc/cpuinfo confirms svebitperm feature flag
• AWS Graviton 3 (c7g) has SVE but NOT SVE2/BitPerm

[rustbot]

r? @sayantn

rustbot has assigned @sayantn.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Amanieu, @folkertdev, @sayantn
• @Amanieu, @folkertdev, @sayantn expanded to Amanieu, folkertdev, sayantn
• Random selection from Amanieu, folkertdev, sayantn

[folkertdev]

Does this even make sense yet? The arm work in the main repo is still ongoing. We might instead want to generate this from the yaml specification instead too?

[ADunfield]

I need it for a project I am working on.

[davidtwco]

I appreciate the interest in upstreaming some SVE intrinsics, but I'd prefer we wait until these are added as part of #2071 (actively being worked on) - this adds a lot more SVE intrinsics and uses our intrinsic generator to do it, which should be more maintainable long-term. We're also still working to resolve some implementation issues in rustc related to scalable vectors as part of that work.

[Amanieu]

As per @davidtwco's comment, I'm going to close this in favor of #2071. We are very close to being able to land that PR and this one would only cause conflicts.