Tracking issue for RFC 2045: improving `#[target_feature]` #44839

alexcrichton · 2017-09-25T14:18:52Z

gnzlbg · 2017-09-26T10:07:45Z

@alexchrichton

Yes, we should also clear some of the unresolved questions:

consensus on the API for run-time feature detection
should cfg!(feature) work across #[inline(always)] functions, generics, etc?

And some related tasks:

API breaking change: allow #[target_feature] on unsafe functions only
API breaking change: #[target_feature = "+feature"] => #[target_feature(enable = "feature")]
fix bug: cfg_target_feature and target_feature don't interact properly #42515
resolve bug: repr(simd) is unsound #44367

It would be nice if those API breaking changes could be prioritized.

retep998 · 2017-09-26T13:54:56Z

Rust already will sometimes not inline a #[inline(always)] function (notably recursive situations), so unsafe code already can't assume that #[inline(always)] code will always be inlined.

gnzlbg · 2017-09-26T14:13:19Z

@retep998 cfg!(feature) does not require any unsafe code.

retep998 · 2017-09-26T15:07:17Z

@gnzlbg I meant in regards to where the RFC states that #[target_feature] and #[inline(always)] mixed together should result in an error. We can simply not inline functions in that case, even if they are marked as #[inline(always)], because Rust will already sometimes not inline functions marked #[inline(always)].

gnzlbg · 2017-09-26T16:31:50Z

@retep998 We could definitely relax this by just not inlining an #[inline(always)] function. I don't know if we want to do so: the user did not write inline, but inline(always), we should at least warn here.

What we cannot currently do is inlining a function across mismatching features (independently of its inlining annotations). The alternative sections of the RFC explores this a bit though.

newpavlov · 2018-03-06T20:46:03Z

Any news on implementation status of --enable-features="feature0,feature1,..." proposed in the RFC?

gnzlbg · 2018-04-04T16:05:31Z

@newpavlov this is being discussed in ~~issue 49658~~ . (note from pnkfelix: did this mean to say #49653 ?)

alexcrichton · 2018-04-04T19:46:24Z

#48556 has entered FCP which I believe will implicitly stabilize this attribute

gnzlbg · 2018-04-04T20:13:55Z

So after the inline-always fix it looks like the only bug open still being tracked here is #42515 .

gnzlbg · 2018-04-04T20:24:24Z

That bug looks hard to solve and probably won't make it before stabilization.

The following issues look "easy" to fix low-hanging fruit. It might be worth to fix these before stabilization:

Add support for MIPS VZ ISA extension [Link to relevant LLVM line where virt extension is specified](https://github.com/llvm/llvm-project/blob/83fab8cee9d6b9fa911195c20325b4512a7a22ef/llvm/lib/Target/Mips/Mips.td#L172-L173) This has been tested on mips-unknown-linux-musl with a target-cpu that is >= MIPS32 5 and `target-features=+virt`. The example was checked in a disassembler to ensure the correct assembly sequence was being generated using the virtualization instructions. Needed additional work: * MIPS is missing from [the Rust reference CPU feature lists](https://doc.rust-lang.org/reference/attributes/codegen.html#available-features) Example docs for later: ```md #### `mips` or `mips64` This platform requires that `#[target_feature]` is only applied to [`unsafe` functions][unsafe function]. This target's feature support is currently unstable and must be enabled by `#![feature(mips_target_feature)]` ([Issue rust-lang#44839]) [Issue rust-lang#44839]: rust-lang#44839 Further documentation on these features can be found in the [MIPS Instruction Set Reference Manual], or elsewhere on [mips.com]. [MIPS Instruction Set Reference Manual]: https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00086-2B-MIPS32BIS-AFP-6.06.pdf [developer.arm.com]: https://www.mips.com/products/architectures/ase/ Feature | Implicitly Enables | Description ---------------|--------------------|------------------- `fp64` | | 64-bit Floating Point `msa` | | "MIPS SIMD Architecture" `virt` | | Virtualization instructions (VZ ASE) ``` If the above is good I can also submit a PR for that if there's interest in documenting it while it's still unstable. Otherwise that can be dropped, I just wrote it before realizing it was possibly not a good idea. Relevant to rust-lang#44839

…ature, r=petrochenkov Stabilize f16c_target_feature Resolves rust-lang/stdarch#1234 Library PR for stabilizing corresponding intrinsics: rust-lang/stdarch#1366 See also rust-lang#44839 tracking issue for target_feature

bkolligs · 2023-02-25T00:35:34Z

Any update on AVX 512 support?

Stabilize cmpxchg16b_target_feature Tracking issue for target features + rust-lang#44839 stdarch issue + rust-lang/stdarch#827 stdarch PR + rust-lang/stdarch#1358 reference PR + rust-lang/reference#1331 It's my first time contributing to rust-lang/rust. Please tell me if I missed something.

qwandor · 2023-06-02T13:13:40Z

Hi, is there anything blocking stabilising arm_target_feature?

coastalwhite · 2023-08-06T12:36:46Z

Hey! I am currently implementing RISC-V Zk intrinsics, and I am running into a pattern that is currently not well covered by this PR.

Either Zkne and Zknd extension needs to be enabled to get access to an intrinsic. I imagine for the compiler it is enough to write:

#[target_feature(enable = "zkne")]
pub unsafe fn aes64ks1i(...) -> ... {
     ...
}

But this produces wrong cargo doc output and can be misleading. Namely, it states that zkne needs to be enabled.

#[target_feature(enable = "zkne", enable = "zknd")]
// OR
#[target_feature(enable = "zkne")]
#[target_feature(enable = "zknd")]
pub unsafe fn aes64ks1i(...) -> ... {
     ...
}

Produces zkne AND zknd.

#[target_feature(enable = "zkne,zknd")]
pub unsafe fn aes64ks1i(...) -> ... {
     ...
}

Produces zkne,zknd which does not exist.

I feel like this is only a documentation issue, but still an issue.

majaha · 2023-08-21T09:55:40Z

I'm not sure if this is the right place for this, but the wasm feature #[target_feature(enable = "multivalue")] is broken at the moment, as it leaks into other untagged functions: Godbolt
This is essentially for the same reasons I've outline here: #83788 (comment)
There may be other target features with similar non-local behaviour, I haven't tested them all.

…features, r=Amanieu Stabilize Ratified RISC-V Target Features Stabilization PR for the ratified RISC-V target features. This stabilizes some of the target features tracked by rust-lang#44839. This is also a part of rust-lang#114544 and eventually needed for the RISC-V part of rust-lang/rfcs#3268. There is a similar PR for the the stdarch crate which can be found at rust-lang/stdarch#1476. This was briefly discussed on Zulip (https://rust-lang.zulipchat.com/#narrow/stream/250483-t-compiler.2Frisc-v/topic/Stabilization.20of.20RISC-V.20Target.20Features/near/394793704). Specifically, this PR stabilizes the: * Atomic Instructions (A) on v2.0 * Compressed Instructions (C) on v2.0 * ~Double-Precision Floating-Point (D) on v2.2~ * ~Embedded Base (E) (Given as `RV32E` / `RV64E`) on v2.0~ * ~Single-Precision Floating-Point (F) on v2.2~ * Integer Multiplication and Division (M) on v2.0 * ~Vector Operations (V) on v1.0~ * Bit Manipulations (B) on v1.0 listed as `zba`, `zbc`, `zbs` * Scalar Cryptography (Zk) v1.0.1 listed as `zk`, `zkn`, `zknd`, `zkne`, `zknh`, `zkr`, `zks`, `zksed`, `zksh`, `zkt`, `zbkb`, `zbkc` `zkbx` * ~Double-Precision Floating-Point in Integer Register (Zdinx) on v1.0~ * ~Half-Precision Floating-Point (Zfh) on v1.0~ * ~Minimal Half-Precision Floating-Point (Zfhmin) on v1.0~ * ~Single-Precision Floating-Point in Integer Register (Zfinx) on v1.0~ * ~Half-Precision Floating-Point in Integer Register (Zhinx) on v1.0~ * ~Minimal Half-Precision Floating-Point in Integer Register (Zhinxmin) on v1.0~ r? `@Amanieu`

jhorstmann · 2023-11-13T22:09:16Z

I tried reading through the open issues regarding target features, but could not find a more fitting one for this question. I have the following code, which currently returns different values on stable vs nightly when compiled with -Ctarget-cpu=skx (Godbolt). I would have expected that target-cpu implicitly enables that feature, or a warning/error that the avx512 target features are still unstable.

pub fn preferred_vec_size() -> usize {
    if cfg!(all(target_arch = "x86_64", target_feature = "avx512f")) {
        64
    } else if cfg!(all(target_arch = "x86_64", target_feature="avx")) {
        32
    } else {
        16
    }
}

workingjubilee · 2023-11-13T23:07:50Z

That's... huh. I guess the first branch is being ignored as an invalid feature gate on stable.

tarcieri · 2024-01-09T13:11:24Z

Are there any particular stabilization blockers for feature(avx512_target_feature), or does it just need a stabilization PR?

Edit: response here

alexcrichton added B-unstable Blocker: Implemented in the nightly compiler and unstable. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Sep 25, 2017

alexcrichton mentioned this issue Sep 25, 2017

RFC: target_feature rust-lang/rfcs#2045

Merged

alexcrichton added the A-SIMD Area: SIMD (Single Instruction Multiple Data) label Sep 25, 2017

TimNN added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Sep 27, 2017

This was referenced Feb 26, 2018

#[target_feature="±<feat>"] is not properly checked against whitelist #38900

Closed

Tracking issue for stable SIMD in Rust #48556

Closed

gnzlbg mentioned this issue Apr 4, 2018

Should -Ctarget-feature go straight to LLVM? #49653

Open

alexcrichton mentioned this issue Apr 4, 2018

Stabilize x86/x86_64 SIMD #49664

Merged

Nugine mentioned this issue Apr 13, 2022

Stabilize aarch64 features Nugine/simd#1

Closed

jam1garner mentioned this issue Jul 19, 2022

Add support for MIPS VZ ISA extension #99443

Merged

ojeda mentioned this issue Sep 28, 2022

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

83 tasks

polarathene mentioned this issue Oct 16, 2022

[avx512] General AVX-512 tracking issue Lokathor/safe_arch#77

Closed

starkat99 mentioned this issue Dec 31, 2022

Stabilize f16c_target_feature #106323

Merged

Nugine mentioned this issue Jan 12, 2023

Stabilize cmpxchg16b_target_feature #106774

Merged

workingjubilee added the A-target-feature Area: Enabling/disabling target features like AVX, Neon, etc. label Mar 3, 2023

coastalwhite mentioned this issue Oct 6, 2023

Stabilize Ratified RISC-V Target Features #116485

Merged

daxpedda mentioned this issue Oct 31, 2023

Stabilize Wasm target features that are in phase 4 and 5 #117457

Merged

Shnatsel mentioned this issue Nov 29, 2023

Use AVX-512 when available mcy/vb64#1

Closed

tarcieri mentioned this issue Jan 9, 2024

Add support for using VAES instructions for NI parallel operations. RustCrypto/block-ciphers#396

Closed

tarcieri mentioned this issue Feb 9, 2024

Tracking Issue for AVX512 intrinsics #111137

Open

2 tasks

dcoles mentioned this issue Sep 12, 2024

Support stable Rust toolchain flipperzero-rs/flipperzero#58

Open

4 tasks

taiki-e mentioned this issue Nov 8, 2024

Tracking Issue for sparc_target_feature #132783

Open

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for RFC 2045: improving `#[target_feature]` #44839

Tracking issue for RFC 2045: improving `#[target_feature]` #44839

alexcrichton commented Sep 25, 2017 •

edited by ChrisDenton

Loading

gnzlbg commented Sep 26, 2017

retep998 commented Sep 26, 2017

gnzlbg commented Sep 26, 2017

retep998 commented Sep 26, 2017

gnzlbg commented Sep 26, 2017 •

edited

Loading

newpavlov commented Mar 6, 2018

gnzlbg commented Apr 4, 2018 •

edited by pnkfelix

Loading

alexcrichton commented Apr 4, 2018

gnzlbg commented Apr 4, 2018

gnzlbg commented Apr 4, 2018 •

edited

Loading

bkolligs commented Feb 25, 2023

qwandor commented Jun 2, 2023

coastalwhite commented Aug 6, 2023

majaha commented Aug 21, 2023

jhorstmann commented Nov 13, 2023

workingjubilee commented Nov 13, 2023 •

edited

Loading

tarcieri commented Jan 9, 2024 •

edited

Loading

Tracking issue for RFC 2045: improving #[target_feature] #44839

Tracking issue for RFC 2045: improving #[target_feature] #44839

Comments

alexcrichton commented Sep 25, 2017 • edited by ChrisDenton Loading

gnzlbg commented Sep 26, 2017

retep998 commented Sep 26, 2017

gnzlbg commented Sep 26, 2017

retep998 commented Sep 26, 2017

gnzlbg commented Sep 26, 2017 • edited Loading

newpavlov commented Mar 6, 2018

gnzlbg commented Apr 4, 2018 • edited by pnkfelix Loading

alexcrichton commented Apr 4, 2018

gnzlbg commented Apr 4, 2018

gnzlbg commented Apr 4, 2018 • edited Loading

bkolligs commented Feb 25, 2023

qwandor commented Jun 2, 2023

coastalwhite commented Aug 6, 2023

majaha commented Aug 21, 2023

jhorstmann commented Nov 13, 2023

workingjubilee commented Nov 13, 2023 • edited Loading

tarcieri commented Jan 9, 2024 • edited Loading

Tracking issue for RFC 2045: improving `#[target_feature]` #44839

Tracking issue for RFC 2045: improving `#[target_feature]` #44839

alexcrichton commented Sep 25, 2017 •

edited by ChrisDenton

Loading

gnzlbg commented Sep 26, 2017 •

edited

Loading

gnzlbg commented Apr 4, 2018 •

edited by pnkfelix

Loading

gnzlbg commented Apr 4, 2018 •

edited

Loading

workingjubilee commented Nov 13, 2023 •

edited

Loading

tarcieri commented Jan 9, 2024 •

edited

Loading