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:

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

Stabilize Wasm target features that are in phase 4 and 5 This stabilizes the Wasm target features that are known to be working and in [phase 4 and 5](https://github.com/WebAssembly/proposals/tree/04fa8c810e1dc99ab399e41052a6e427ee988180). Feature stabilized: - [Non-trapping float-to-int conversions](https://github.com/WebAssembly/nontrapping-float-to-int-conversions) - [Import/Export of Mutable Globals](https://github.com/WebAssembly/mutable-global) - [Sign-extension operators](https://github.com/WebAssembly/sign-extension-ops) - [Bulk memory operations](https://github.com/WebAssembly/bulk-memory-operations) - [Extended Constant Expressions](https://github.com/WebAssembly/extended-const) Features not stabilized: - [Multi-value](https://github.com/WebAssembly/multi-value): requires rebuilding `std` #73755. - [Reference Types](https://github.com/WebAssembly/reference-types): no point stabilizing without #103516. - [Threads](https://github.com/webassembly/threads): requires rebuilding `std` #77839. - [Relaxed SIMD](https://github.com/WebAssembly/relaxed-simd): separate PR #117468. - [Multi Memory](https://github.com/WebAssembly/multi-memory): not implemented. See rust-lang/rust#117457 (comment) for more context. Documentation: rust-lang/reference#1420 Tracking issue: rust-lang/rust#44839

sayantn · 2025-03-22T21:39:02Z

Refer to this comment.

The AVX512 situation has been sorted out, and is ready for stabilization

…, r=Amanieu rustc_target: RISC-V: add base `I`-related important extensions Of ratified RISC-V features defined, this commit adds extensions satisfying following criteria: * Formerly a part of the `I` extension and splitted thereafter (now ratified as `I` + `Zifencei` + `Zicsr` + `Zicntr` + `Zihpm`) or * Dicoverable from newer versions of the Linux kernel and implemented as a part of `std_detect`'s feature (`Zihintpause`) and * Available on LLVM 18. This is based on [the latest ratified ISA Manuals (version 20240411)](https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications). LLVM Definitions: * [`Zifencei`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L133-L137) * [`Zicsr`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L116-L120) * [`Zicntr`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L122-L124) * [`Zihpm`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L153-L155) * [`Zihintpause`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L139-L144) Additional (1): One of those, `Zicsr`, is a dependency of many other ISA extensions and this commit adds correct dependencies to `Zicsr`. Additional (2): In RISC-V, `G` is an abbreviation of following extensions: * `I` * `M` * `A` * `F` * `D` * `Zicsr` (although implied by `F`) * `Zifencei` and all RISC-V targets with the `G` abbreviation and targets for Android / VxWorks are updated accordingly. Note: Android will require RVA22 (likely RVA22U64) and some more extensions, which is a superset of RV64GC. For VxWorks, all BSPs currently distributed by Wind River are for boards with RV64GC (this commit also updates `riscv32-wrs-vxworks` though). -------- This is the version 4. `Ztso` in the original proposal is removed on the PR version 2 due to the minimum LLVM version (non-experimental `Ztso` requires LLVM 19 while minimum LLVM version of Rust is 18). This is not back in PR version 3 and 4 after noticing adding `Ztso` is possible by checking host LLVM version because PR version 3 introduces compiler target changes (and adding more extensions would complicate the problems; sorry `Zihintpause`). Version 4: * Fixed some commit messages, * Added Android / VxWorks targets to imply `G` and * Added an implication from `Zve32x` to `Zicsr` (which makes all vector extension subsets to imply `Zicsr`) since rust-lang#138742 is now merged. Related: * rust-lang#44839 (`riscv_target_feature`) * rust-lang#114544 (This PR can be a prerequisite of resolving a part of that tracking issue) * rust-lang#138742 (Touches the same place and vector extensions depend on `Zicsr`) NOT Related but linked: * rust-lang#132618 (This PR won't be blocked by this issue since none of those extensions do not change the ABI) `@rustbot` r? `@Amanieu` `@rustbot` label +T-compiler +O-riscv +A-target-feature

Rollup merge of rust-lang#138823 - a4lg:riscv-feature-addition-base-i, r=Amanieu rustc_target: RISC-V: add base `I`-related important extensions Of ratified RISC-V features defined, this commit adds extensions satisfying following criteria: * Formerly a part of the `I` extension and splitted thereafter (now ratified as `I` + `Zifencei` + `Zicsr` + `Zicntr` + `Zihpm`) or * Dicoverable from newer versions of the Linux kernel and implemented as a part of `std_detect`'s feature (`Zihintpause`) and * Available on LLVM 18. This is based on [the latest ratified ISA Manuals (version 20240411)](https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications). LLVM Definitions: * [`Zifencei`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L133-L137) * [`Zicsr`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L116-L120) * [`Zicntr`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L122-L124) * [`Zihpm`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L153-L155) * [`Zihintpause`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L139-L144) Additional (1): One of those, `Zicsr`, is a dependency of many other ISA extensions and this commit adds correct dependencies to `Zicsr`. Additional (2): In RISC-V, `G` is an abbreviation of following extensions: * `I` * `M` * `A` * `F` * `D` * `Zicsr` (although implied by `F`) * `Zifencei` and all RISC-V targets with the `G` abbreviation and targets for Android / VxWorks are updated accordingly. Note: Android will require RVA22 (likely RVA22U64) and some more extensions, which is a superset of RV64GC. For VxWorks, all BSPs currently distributed by Wind River are for boards with RV64GC (this commit also updates `riscv32-wrs-vxworks` though). -------- This is the version 4. `Ztso` in the original proposal is removed on the PR version 2 due to the minimum LLVM version (non-experimental `Ztso` requires LLVM 19 while minimum LLVM version of Rust is 18). This is not back in PR version 3 and 4 after noticing adding `Ztso` is possible by checking host LLVM version because PR version 3 introduces compiler target changes (and adding more extensions would complicate the problems; sorry `Zihintpause`). Version 4: * Fixed some commit messages, * Added Android / VxWorks targets to imply `G` and * Added an implication from `Zve32x` to `Zicsr` (which makes all vector extension subsets to imply `Zicsr`) since rust-lang#138742 is now merged. Related: * rust-lang#44839 (`riscv_target_feature`) * rust-lang#114544 (This PR can be a prerequisite of resolving a part of that tracking issue) * rust-lang#138742 (Touches the same place and vector extensions depend on `Zicsr`) NOT Related but linked: * rust-lang#132618 (This PR won't be blocked by this issue since none of those extensions do not change the ABI) `@rustbot` r? `@Amanieu` `@rustbot` label +T-compiler +O-riscv +A-target-feature

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: An issue tracking the progress of sth. like the implementation of an RFC 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

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

RalfJung mentioned this issue Nov 16, 2024

Tracking Issue for x86 target feature x87 (x87_target_feature) #133098

Closed

4 tasks

taiki-e mentioned this issue Dec 15, 2024

Tracking Issue for m68k_target_feature #134328

Open

2 tasks

heiher mentioned this issue Jan 2, 2025

Partially stabilize LoongArch target features #135015

Open

This was referenced Mar 19, 2025

add nvptx_target_feature EnzymeAD/rust#195

Closed

add nvptx_target_feature #138689

Open

This was referenced Mar 22, 2025

rustc_target: Sync with stdarch (important parts) #138820

Closed

rustc_target: RISC-V: add base I-related important extensions #138823

Merged

sayantn mentioned this issue Mar 22, 2025

Tracking Issue for AVX10 target features #138843

Open

a4lg mentioned this issue Mar 24, 2025

rustc_target: RISC-V Zfinx is incompatible with {ILP32,LP64}[FD] ABIs #138872

Open

sayantn mentioned this issue Mar 25, 2025

Stabilize the avx512 target features #138940

Open

a4lg mentioned this issue Apr 6, 2025

rustc_target: RISC-V: feature addition batch 2 #139440

Open

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

majaha commented Aug 21, 2023

jhorstmann commented Nov 13, 2023

workingjubilee commented Nov 13, 2023 •

edited

Loading

tarcieri commented Jan 9, 2024 •

edited

Loading

sayantn commented Mar 22, 2025

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

majaha commented Aug 21, 2023

jhorstmann commented Nov 13, 2023

workingjubilee commented Nov 13, 2023 • edited Loading

tarcieri commented Jan 9, 2024 • edited Loading

sayantn commented Mar 22, 2025

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