Tracking issue for `cfg_target_feature`

[aturon]

Added as part of the SIMD work, supports feature detection based on e.g. target processor. This issue tracks stabilization.

Relevant issues and bugs

• repr(simd) is unsound #44367 -- repr(simd) is unsound

[alexcrichton]

The only known issue with this I'm aware of is that it doesn't doesn't use the same mechanism in LLVM to query whether a feature is activated or not. We already maintain our own list of what features are allowed here (e.g. we're not just exposing what LLVM accepts) and then we currently map that down to an LLVM feature name. When testing whether the LLVM feature is activated, however, we should robustly query LLVM via its own internal mechanisms rather than explicitly checking ourselves.

[gnzlbg]

I opened a separate issue #30462 for the missing cfg_target_feature for bit manipulation instruction sets.

[alexcrichton]

cfg target_feature -- for github issue searchability as well

also a new forum link -- https://internals.rust-lang.org/t/comprehensive-list-of-desired-cfg-target-feature-s/3201

[gnzlbg]

So this is a list of the current target features supported by llc -mattr=help:

16bit-mode             - 16-bit mode (i8086).
  32bit-mode             - 32-bit mode (80386).
  3dnow                  - Enable 3DNow! instructions.
  3dnowa                 - Enable 3DNow! Athlon instructions.
  64bit                  - Support 64-bit instructions.
  64bit-mode             - 64-bit mode (x86_64).
  adx                    - Support ADX instructions.
  aes                    - Enable AES instructions.
  atom                   - Intel Atom processors.
  avx                    - Enable AVX instructions.
  avx2                   - Enable AVX2 instructions.
  avx512bw               - Enable AVX-512 Byte and Word Instructions.
  avx512cd               - Enable AVX-512 Conflict Detection Instructions.
  avx512dq               - Enable AVX-512 Doubleword and Quadword Instructions.
  avx512er               - Enable AVX-512 Exponential and Reciprocal Instructions.
  avx512f                - Enable AVX-512 instructions.
  avx512ifma             - Enable AVX-512 Integer Fused Multiple-Add.
  avx512pf               - Enable AVX-512 PreFetch Instructions.
  avx512vbmi             - Enable AVX-512 Vector Bit Manipulation Instructions.
  avx512vl               - Enable AVX-512 Vector Length eXtensions.
  bmi                    - Support BMI instructions.
  bmi2                   - Support BMI2 instructions.
  call-reg-indirect      - Call register indirect.
  clflushopt             - Flush A Cache Line Optimized.
  clwb                   - Cache Line Write Back.
  cmov                   - Enable conditional move instructions.
  cx16                   - 64-bit with cmpxchg16b.
  f16c                   - Support 16-bit floating point conversion instructions.
  fast-partial-ymm-write - Partial writes to YMM registers are fast.
  fma                    - Enable three-operand fused multiple-add.
  fma4                   - Enable four-operand fused multiple-add.
  fsgsbase               - Support FS/GS Base instructions.
  fxsr                   - Support fxsave/fxrestore instructions.
  hle                    - Support HLE.
  idivl-to-divb          - Use 8-bit divide for positive values less than 256.
  idivq-to-divw          - Use 16-bit divide for positive values less than 65536.
  invpcid                - Invalidate Process-Context Identifier.
  lea-sp                 - Use LEA for adjusting the stack pointer.
  lea-uses-ag            - LEA instruction needs inputs at AG stage.
  lzcnt                  - Support LZCNT instruction.
 mmx                    - Enable MMX instructions.
  movbe                  - Support MOVBE instruction.
  mpx                    - Support MPX instructions.
  mwaitx                 - Enable MONITORX/MWAITX timer functionality.
  pad-short-functions    - Pad short functions.
  pclmul                 - Enable packed carry-less multiplication instructions.
  pcommit                - Enable Persistent Commit.
  pku                    - Enable protection keys.
  popcnt                 - Support POPCNT instruction.
  prefetchwt1            - Prefetch with Intent to Write and T1 Hint.
  prfchw                 - Support PRFCHW instructions.
  rdrnd                  - Support RDRAND instruction.
  rdseed                 - Support RDSEED instruction.
  rtm                    - Support RTM instructions.
  sahf                   - Support LAHF and SAHF instructions.
  sgx                    - Enable Software Guard Extensions.
  sha                    - Enable SHA instructions.
  slm                    - Intel Silvermont processors.
  slow-bt-mem            - Bit testing of memory is slow.
  slow-incdec            - INC and DEC instructions are slower than ADD and SUB.
  slow-lea               - LEA instruction with certain arguments is slow.
  slow-shld              - SHLD instruction is slow.
  slow-unaligned-mem-16  - Slow unaligned 16-byte memory access.
  slow-unaligned-mem-32  - Slow unaligned 32-byte memory access.
  smap                   - Supervisor Mode Access Protection.
  soft-float             - Use software floating point features..
  sse                    - Enable SSE instructions.
  sse-unaligned-mem      - Allow unaligned memory operands with SSE instructions.
  sse2                   - Enable SSE2 instructions.
  sse3                   - Enable SSE3 instructions.
  sse4.1                 - Enable SSE 4.1 instructions.
  sse4.2                 - Enable SSE 4.2 instructions.
  sse4a                  - Support SSE 4a instructions.
  ssse3                  - Enable SSSE3 instructions.
  tbm                    - Enable TBM instructions.
  vmfunc                 - VM Functions.
  x87                    - Enable X87 float instructions.
  xop                    - Enable XOP instructions.
  xsave                  - Support xsave instructions.
  xsavec                 - Support xsavec instructions.
  xsaveopt               - Support xsaveopt instructions.
  xsaves                 - Support xsaves instructions.

Would a patch that implements macros for all of these need to go through the RFC process?

[aturon]

cc @BurntSushi @eddyb @nikomatsakis -- I believe all of you were recently involved in discussion around SIMD stabilization.

[bluss]

This would be useful to use in matrixmultiply, ndarray even before simd stabilization. I get better results if I can pick the particular stable rust-implemented loop that generates best code given the particular available vector types / available target features.

[briansmith]

For people interested in helping with this:

There is a allowlist of features that are exposed by this mechanism, which is very limited. See https://github.com/rust-lang/rust/blob/master/src/librustc_driver/target_features.rs#L23-L28, in particular the variables ARM_WHITELIST and X86_WHITELIST.

I found #34412 which seems to be a good example of a PR that expands the set of features that can be used with #[cfg(target_feature=)]. It looks straightforward to create more PRs that expose more features, and I encourage people to do so.

[briansmith]

When testing whether the LLVM feature is activated, however, we should robustly query LLVM via its own internal mechanisms rather than explicitly checking ourselves.

Is this blocking stabilization of this feature? And, if so, is this the only thing blocking stabilization, or are there other things?

[briansmith]

When testing whether the LLVM feature is activated, however, we should robustly query LLVM via its own internal mechanisms rather than explicitly checking ourselves.

Is this blocking stabilization of this feature? And, if so, is this the only thing blocking stabilization, or are there other things?

To answer my own question: IMO, the above concern doesn't need to block this feature from being stabilized. In my case, I don't care whether LLVM has the CPU features enabled in its code generation because I'm not using LLVM-based code gen for my code that uses SIMD and stuff.

The above concern does need to block the stabilization of intrinsics and other things exposed from libcore/libstd that depend on #[cfg(target-feature)], but that's separate from exposing #[cfg(target-feature)] itself, and that should happen in the tracking issues for those features, not this one.

So, IMO, this seems like it this is good to go.

[briansmith]

One clarification might be in order: When code uses this feature, can it assume that every feature name will be globally unique, or should it assume that feature names might be reused across different architectures. For example, would a feature "+crypto" imply AAarch32 or AAarch64, or is it possible that, say, a MIPS target could have a "+crypto" feature? In some instances this would affect whether one writes this:

#[cfg(target_feature="crypto")]

or this:

#[cfg(all(target_feature="crypto", any(target="aarch64", target="aarch32")))]

[alexcrichton]

@briansmith AFAIK this issue is not block on anything. The concern you linked to about querying LLVM directly was actually resolved back in April!

Also AFAIK we haven't discussed issues of namespaces or implication of features across architectures.