Stabilize LoongArch64 SIMD Intrinsics

[heiher]

Tracking issue: rust-lang/rust#162508

LoongArch64 SIMD intrinsics are already used by rustc itself and by a number of downstream projects. Experience from these real-world uses indicates that the API is ready for stabilization. Stabilizing the intrinsics would remove the nightly requirement for applications that currently depend on them.

API surface

• core::arch::loongarch64::lsx_*
• core::arch::loongarch64::lasx_*

Note for subtree update

Remove this line: https://github.com/rust-lang/rust/blob/1edd55dcfcd573872c727fa3e086369a71661ee0/compiler/rustc_span/src/lib.rs#L20

[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

[tgross35]

What's the reason for changing the feature name?

View changes since the review

[heiher]

What's the reason for changing the feature name?

There are also some unstable APIs gated by stdarch_loongarch. Having both stable and unstable APIs gated by the same feature name causes the following error:

error[E0711]: feature `stdarch_loongarch` is declared stable, but was previously declared unstable

Also, putting the SIMD intrinsics under stdarch_loongarch_simd makes the categorization more explicit, similar to stdarch_loongarch_crc.

[tgross35]

Note that this stabilizes more cases of rustc_legacy_const_generics, which was discussed at rust-lang/rust#149654. Cc @rust-lang/lang

Nominating since that's probably worth clarifying, and also this is a lot of surface area with potential sharp edges.

@rustbot label +I-libs-nominated

[rustbot]

Error: The feature relabel is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[heiher]

Note that this stabilizes more cases of rustc_legacy_const_generics, which was discussed at rust-lang/rust#149654.

Thanks for pointing this out. As far as I know, no projects currently depend on the LoongArch SIMD API signatures using the rustc_legacy_const_generics form, so there are no legacy compatibility concerns here. If adding new instances of rustc_legacy_const_generics is not desirable, we can simply remove it.

[heiher]

rustc_legacy_const_generics has been removed from LoongArch64 SIMD in v2.

[clarfonthey]

@rfcbot merge libs

[rust-rfcbot]

@clarfonthey has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @cuviper
• @dtolnay
• @joshtriplett
• @the8472
• @thomcc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Amanieu]

It would be nice to have this fuzz tested against the C intrinsics using intrinsic-test before stabilizing.

@rfcbot concern fuzz testing

[adamgemmell]

There was a previous attempt at doing so at #1900, though it never fully passed CI and will need some rebasing.

[heiher]

There was a previous attempt at doing so at #1900, though it never fully passed CI and will need some rebasing.

Thanks! There's a new impl in #2226 with all related CI checks passing.

[traviscross]

With these intrinsics, Miri reports UB in safe code:

#![feature(stdarch_loongarch)]
use std::arch::is_loongarch_feature_detected;
use std::arch::loongarch64::*;

#[target_feature(enable = "lsx")]
fn probe() -> i32 {
  let ones = lsx_vrepli_b::<1>();
  let zero = lsx_vrepli_b::<0>();
  let r = lsx_vdiv_b(ones, zero);
  lsx_vpickve2gr_b::<0>(r)
}

fn main() {
  if is_loongarch_feature_detected!("lsx") {
    // SAFETY: We just checked: the `lsx` feature is present.
    let lane0 = unsafe { probe() };
    println!("lane 0 = {lane0}");
  }
}

Godbolt link

From #2078, see:

• https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/stdarch/pull/2078#discussion_r3121430126
• https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/stdarch/pull/2078#discussion_r3121435644
• https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/stdarch/pull/2078#discussion_r3121452899

cc @sayantn

[heiher]

With these intrinsics, Miri reports UB in safe code:

Good catch!

I double-checked this with the LoongArch ISA developer. It differs from the previous comment in PR #2078. The ISA defines vdiv/vmod to return 0 if the divisor is 0. (This behavior will be documented in the SIMD reference)

So it seems we can't use portable simd_div/simd_rem here. I'll revert this part. Any other better approach? Thanks!

[Amanieu]

There are 2 options, depending on what the intrinsic behavior should be:

1. Make it unsafe and declare that it is UB if any vector lane of the divisor is 0.
2. Keep it safe and use LLVM target-specific intrinsics or inline asm to implement it.

[heiher]

There are 2 options, depending on what the intrinsic behavior should be:

1. Make it unsafe and declare that it is UB if any vector lane of the divisor is 0.
2. Keep it safe and use LLVM target-specific intrinsics or inline asm to implement it.

Thanks! A new PR has been created based on option 2: #2229