Stabilize LoongArch CRC Intrinsics

[heiher]

implementation: #1688
tracking issue: rust-lang/rust#156908

Following a proposal from @folkertdev and downstream interest from zlib-rs (trifectatechfoundation/zlib-rs#511), this PR proposes stabilizing the LoongArch CRC intrinsics.

Since the API only operates on scalar integer types, there are no major ABI concerns around stabilization.

API surface

The stdarch_loongarch_crc feature exposes 8 functions:

/// Calculate the CRC value using the IEEE 802.3 polynomial (0xEDB88320)
pub fn crc_w_b_w(a: i8, b: i32) -> i32

/// Calculate the CRC value using the IEEE 802.3 polynomial (0xEDB88320)
pub fn crc_w_h_w(a: i16, b: i32) -> i32

/// Calculate the CRC value using the IEEE 802.3 polynomial (0xEDB88320)
pub fn crc_w_w_w(a: i32, b: i32) -> i32

/// Calculate the CRC value using the IEEE 802.3 polynomial (0xEDB88320)
pub fn crc_w_d_w(a: i64, b: i32) -> i32 

/// Calculate the CRC value using the Castagnoli polynomial (0x82F63B78)
pub fn crcc_w_b_w(a: i8, b: i32) -> i32

/// Calculate the CRC value using the Castagnoli polynomial (0x82F63B78)
pub fn crcc_w_h_w(a: i16, b: i32) -> i32

/// Calculate the CRC value using the Castagnoli polynomial (0x82F63B78)
pub fn crcc_w_w_w(a: i32, b: i32) -> i32

/// Calculate the CRC value using the Castagnoli polynomial (0x82F63B78)
pub fn crcc_w_d_w(a: i64, b: i32) -> i32

[rustbot]

r? @folkertdev

rustbot has assigned @folkertdev.
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, @adamgemmell, @davidtwco, @folkertdev, @sayantn
• @Amanieu, @adamgemmell, @davidtwco, @folkertdev, @sayantn expanded to Amanieu, adamgemmell, davidtwco, folkertdev, sayantn
• Random selection from Amanieu, adamgemmell, davidtwco, folkertdev, sayantn

[folkertdev]

Nice, can you open a new tracking issue for the new feature you just added (roughly similar to rust-lang/rust#117224, but copy the whole api surface section from your post here, that's convenient).

I'll then nominate that tracking issue for T-libs-api to look at, and they can start the stabilization process. Pointing out the similarity to rust-lang/rust#117215 is also useful, as well as the fact that these intrinsics do not require a target feature

[folkertdev]

And also perhaps clarify that these are only defined on loongarch64, not on loongarch32

[heiher]

@folkertdev A new tracking issue: rust-lang/rust#156908

[Gelbpunkt]

Thanks for proposing this! I agree it makes sense to stabilize these intrinsics and I'm happy with them now that the signatures match Clang's, but I'm not 100% sure about the names yet. In Clang, all of these have an __ prefix, e.g. __crc_w_b_w (https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/larchintrin.h#L58-L104). If it is desired to match Clang in that regard as well, that should be changed before stabilization.

[heiher]

Thanks for proposing this! I agree it makes sense to stabilize these intrinsics and I'm happy with them now that the signatures match Clang's, but I'm not 100% sure about the names yet. In Clang, all of these have an __ prefix, e.g. __crc_w_b_w (https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/larchintrin.h#L58-L104). If it is desired to match Clang in that regard as well, that should be changed before stabilization.

We previously discussed the naming of the Rust intrinsics and intentionally removed the double underscores.