What should be do about the stdsimd feature?

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

  • x86: is behind the simd_x86 feature
  • 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 .

Start with the stdsimd feature-gate checklist in this issue and review the referenced tracking issues #148, #170, #463, and #462. Determine the intended feature names and exposure decisions for core::simd, architecture modules, and nvptx, and clarify which tracking work belongs in rust-lang/rust; done means those decisions and issue links are recorded.