What should be do about the stdsimd feature?

[gnzlbg]

We are exposing a bunch of stuff from coresimd and everything is behind the same feature gate stdsimd:

core:

• [ ] simd: should probably be behind its own feature name core_simd, portable_simd or similar

• arch: is behind the simd_arch feature

  • [x] x86: is behind the simd_x86 feature
  • [x] x86_64: is behind the simd_x86 feature
  • [ ] arm/aarch64: should be behind the simd_arm feature
  • [ ] wasm32: simd_wasm? @alexcrichton
  • [ ] mips/mips64: should be behind the simd_mips feature
  • [ ] powerpc/powerpc64: should be behind the simd_ppc feature

---

Also, the nvptx module is not exposed anymore. I can't recall the exact reason but remember that there was one. In any case, should we add some feature name for it (e.g. nvptx_arch) and expose it again?

---

Also, some of the tracking issues for these things are in the stdsimd repo, do we need to open issues in rust-lang/rust for them ?

• arm: #148
• mips: #170
• powerpc: #463, #462

For the core::simd issue I think it's ok to keep it pointing to the tracking issue of the original RFC by @huonw .

[alexcrichton]

Sure yeah seems fine by me to move them behind per-platform features, they're likely to stabilize per-platform anyway!

[lu-zero]

Add https://github.com/rust-lang-nursery/stdsimd/issues/463 and https://github.com/rust-lang-nursery/stdsimd/issues/462 for Altivec and VSX.