Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for struct_target_features (RFC 3525) #129107

Open
4 tasks
veluca93 opened this issue Aug 14, 2024 · 0 comments
Open
4 tasks

Tracking Issue for struct_target_features (RFC 3525) #129107

veluca93 opened this issue Aug 14, 2024 · 0 comments
Labels
B-experimental Blocker: In-tree experiment; RFC pending or unneeded. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-struct_target_features `#![feature(struct_target_features)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@veluca93
Copy link
Contributor

veluca93 commented Aug 14, 2024

This is a tracking issue for the RFC "struct target features" (rust-lang/rfcs#3525).
The feature gate for the issue is #![feature(struct_target_features)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

Unresolved Questions

  • Should functions with witness types as arguments implement Fn traits?
@veluca93 veluca93 added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Aug 14, 2024
@BoxyUwU BoxyUwU added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Aug 16, 2024
@traviscross traviscross added F-struct_target_features `#![feature(struct_target_features)]` T-lang Relevant to the language team, which will review and decide on the PR/issue. B-experimental Blocker: In-tree experiment; RFC pending or unneeded. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 27, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 28, 2024
Implement a first version of RFC 3525: struct target features

This PR is an attempt at implementing rust-lang/rfcs#3525, behind a feature gate `struct_target_features`.

There's obviously a few tasks that ought to be done before this is merged; in no particular order:
- add proper error messages
- add tests
- create a tracking issue for the RFC
- properly serialize/deserialize the new target_features field in `rmeta` (assuming I even understood that correctly :-))

That said, as I am definitely not a `rustc` expert, I'd like to get some early feedback on the overall approach before fixing those things (and perhaps some pointers for `rmeta`...), hence this early PR :-)

Here's an example piece of code that I have been using for testing - with the new code, the calls to intrinsics get correctly inlined:
```rust
#![feature(struct_target_features)]

use std::arch::x86_64::*;

/*
// fails to compile
#[target_feature(enable = "avx")]
struct Invalid(u32);
*/

#[target_feature(enable = "avx")]
struct Avx {}

#[target_feature(enable = "sse")]
struct Sse();

/*
// fails to compile
extern "C" fn bad_fun(_: Avx) {}
*/

/*
// fails to compile
#[inline(always)]
fn inline_fun(_: Avx) {}
*/

trait Simd {
    fn do_something(&self);
}

impl Simd for Avx {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm256_setzero_ps());
        }
    }
}

impl Simd for Sse {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm_setzero_ps());
        }
    }
}

struct WithAvx {
    #[allow(dead_code)]
    avx: Avx,
}

impl Simd for WithAvx {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm256_setzero_ps());
        }
    }
}

#[inline(never)]
fn dosomething<S: Simd>(simd: &S) {
    simd.do_something();
}

fn main() {
    /*
    // fails to compile
    Avx {};
    */

    if is_x86_feature_detected!("avx") {
        let avx = unsafe { Avx {} };
        dosomething(&avx);
        dosomething(&WithAvx { avx });
    }
    if is_x86_feature_detected!("sse") {
        dosomething(&unsafe { Sse {} })
    }
}
```

Tracking:

- rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 28, 2024
Implement a first version of RFC 3525: struct target features

This PR is an attempt at implementing rust-lang/rfcs#3525, behind a feature gate `struct_target_features`.

There's obviously a few tasks that ought to be done before this is merged; in no particular order:
- add proper error messages
- add tests
- create a tracking issue for the RFC
- properly serialize/deserialize the new target_features field in `rmeta` (assuming I even understood that correctly :-))

That said, as I am definitely not a `rustc` expert, I'd like to get some early feedback on the overall approach before fixing those things (and perhaps some pointers for `rmeta`...), hence this early PR :-)

Here's an example piece of code that I have been using for testing - with the new code, the calls to intrinsics get correctly inlined:
```rust
#![feature(struct_target_features)]

use std::arch::x86_64::*;

/*
// fails to compile
#[target_feature(enable = "avx")]
struct Invalid(u32);
*/

#[target_feature(enable = "avx")]
struct Avx {}

#[target_feature(enable = "sse")]
struct Sse();

/*
// fails to compile
extern "C" fn bad_fun(_: Avx) {}
*/

/*
// fails to compile
#[inline(always)]
fn inline_fun(_: Avx) {}
*/

trait Simd {
    fn do_something(&self);
}

impl Simd for Avx {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm256_setzero_ps());
        }
    }
}

impl Simd for Sse {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm_setzero_ps());
        }
    }
}

struct WithAvx {
    #[allow(dead_code)]
    avx: Avx,
}

impl Simd for WithAvx {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm256_setzero_ps());
        }
    }
}

#[inline(never)]
fn dosomething<S: Simd>(simd: &S) {
    simd.do_something();
}

fn main() {
    /*
    // fails to compile
    Avx {};
    */

    if is_x86_feature_detected!("avx") {
        let avx = unsafe { Avx {} };
        dosomething(&avx);
        dosomething(&WithAvx { avx });
    }
    if is_x86_feature_detected!("sse") {
        dosomething(&unsafe { Sse {} })
    }
}
```

Tracking:

- rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 28, 2024
Implement a first version of RFC 3525: struct target features

This PR is an attempt at implementing rust-lang/rfcs#3525, behind a feature gate `struct_target_features`.

There's obviously a few tasks that ought to be done before this is merged; in no particular order:
- add proper error messages
- add tests
- create a tracking issue for the RFC
- properly serialize/deserialize the new target_features field in `rmeta` (assuming I even understood that correctly :-))

That said, as I am definitely not a `rustc` expert, I'd like to get some early feedback on the overall approach before fixing those things (and perhaps some pointers for `rmeta`...), hence this early PR :-)

Here's an example piece of code that I have been using for testing - with the new code, the calls to intrinsics get correctly inlined:
```rust
#![feature(struct_target_features)]

use std::arch::x86_64::*;

/*
// fails to compile
#[target_feature(enable = "avx")]
struct Invalid(u32);
*/

#[target_feature(enable = "avx")]
struct Avx {}

#[target_feature(enable = "sse")]
struct Sse();

/*
// fails to compile
extern "C" fn bad_fun(_: Avx) {}
*/

/*
// fails to compile
#[inline(always)]
fn inline_fun(_: Avx) {}
*/

trait Simd {
    fn do_something(&self);
}

impl Simd for Avx {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm256_setzero_ps());
        }
    }
}

impl Simd for Sse {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm_setzero_ps());
        }
    }
}

struct WithAvx {
    #[allow(dead_code)]
    avx: Avx,
}

impl Simd for WithAvx {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm256_setzero_ps());
        }
    }
}

#[inline(never)]
fn dosomething<S: Simd>(simd: &S) {
    simd.do_something();
}

fn main() {
    /*
    // fails to compile
    Avx {};
    */

    if is_x86_feature_detected!("avx") {
        let avx = unsafe { Avx {} };
        dosomething(&avx);
        dosomething(&WithAvx { avx });
    }
    if is_x86_feature_detected!("sse") {
        dosomething(&unsafe { Sse {} })
    }
}
```

Tracking:

- rust-lang#129107
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Aug 29, 2024
Implement a first version of RFC 3525: struct target features

This PR is an attempt at implementing rust-lang/rfcs#3525, behind a feature gate `struct_target_features`.

There's obviously a few tasks that ought to be done before this is merged; in no particular order:
- add proper error messages
- add tests
- create a tracking issue for the RFC
- properly serialize/deserialize the new target_features field in `rmeta` (assuming I even understood that correctly :-))

That said, as I am definitely not a `rustc` expert, I'd like to get some early feedback on the overall approach before fixing those things (and perhaps some pointers for `rmeta`...), hence this early PR :-)

Here's an example piece of code that I have been using for testing - with the new code, the calls to intrinsics get correctly inlined:
```rust
#![feature(struct_target_features)]

use std::arch::x86_64::*;

/*
// fails to compile
#[target_feature(enable = "avx")]
struct Invalid(u32);
*/

#[target_feature(enable = "avx")]
struct Avx {}

#[target_feature(enable = "sse")]
struct Sse();

/*
// fails to compile
extern "C" fn bad_fun(_: Avx) {}
*/

/*
// fails to compile
#[inline(always)]
fn inline_fun(_: Avx) {}
*/

trait Simd {
    fn do_something(&self);
}

impl Simd for Avx {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm256_setzero_ps());
        }
    }
}

impl Simd for Sse {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm_setzero_ps());
        }
    }
}

struct WithAvx {
    #[allow(dead_code)]
    avx: Avx,
}

impl Simd for WithAvx {
    fn do_something(&self) {
        unsafe {
            println!("{:?}", _mm256_setzero_ps());
        }
    }
}

#[inline(never)]
fn dosomething<S: Simd>(simd: &S) {
    simd.do_something();
}

fn main() {
    /*
    // fails to compile
    Avx {};
    */

    if is_x86_feature_detected!("avx") {
        let avx = unsafe { Avx {} };
        dosomething(&avx);
        dosomething(&WithAvx { avx });
    }
    if is_x86_feature_detected!("sse") {
        dosomething(&unsafe { Sse {} })
    }
}
```

Tracking:

- rust-lang/rust#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 29, 2024
struct_target_features: reduce serialized rmeta

Reduce the amount of serialized information in rmeta. This should fix the binary size regression in rust-lang#127537 and *may* also fix the speed regression.

r? compiler-errors

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 29, 2024
struct_target_features: reduce serialized rmeta

Reduce the amount of serialized information in rmeta. This should fix the binary size regression in rust-lang#127537 and *may* also fix the speed regression.

r? compiler-errors

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 30, 2024
struct_target_features: cache feature computation.

This commit moves the type-recursion to a query, causing it to be cached and (hopefully!)
fixing the instruction-count regression from rust-lang#127537.

r? compiler-errors

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 2, 2024
Implement struct_target_features for non-generic functions.

This PR implements a first version of RFC 3525. In particular, the current code does not handle structs with target features being passed to generic functions correctly.

This is a roll-up of rust-lang#129764, rust-lang#129783 and rust-lang#129764, which will hopefully result in a PR that does not introduce perf regressions in the first place.

r? Kobzol

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 2, 2024
Implement struct_target_features for non-generic functions.

This PR implements a first version of RFC 3525. In particular, the current code does not handle structs with target features being passed to generic functions correctly.

This is a roll-up of rust-lang#129764, rust-lang#129783 and rust-lang#129764, which will hopefully result in a PR that does not introduce perf regressions in the first place.

r? Kobzol

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 10, 2024
Implement struct_target_features for non-generic functions.

This PR implements a first version of RFC 3525. In particular, the current code does not handle structs with target features being passed to generic functions correctly.

This is a roll-up of rust-lang#129764, rust-lang#129783 and rust-lang#129764, which will hopefully result in a PR that does not introduce perf regressions in the first place.

r? Kobzol

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 10, 2024
Implement struct_target_features for non-generic functions.

This PR implements a first version of RFC 3525. In particular, the current code does not handle structs with target features being passed to generic functions correctly.

This is a roll-up of rust-lang#129764, rust-lang#129783 and rust-lang#129764, which will hopefully result in a PR that does not introduce perf regressions in the first place.

r? Kobzol

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 13, 2024
Implement struct_target_features for non-generic functions.

This PR implements a first version of RFC 3525. In particular, the current code does not handle structs with target features being passed to generic functions correctly.

This is a roll-up of rust-lang#129764, rust-lang#129783 and rust-lang#129764, which will hopefully result in a PR that does not introduce perf regressions in the first place.

r? Kobzol

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 5, 2024
Implement struct_target_features.

This PR implements a first version of RFC 3525.

This is a roll-up of rust-lang#129764, rust-lang#129783 and rust-lang#129764, which will hopefully result in a PR that does not introduce perf regressions in the first place.

This PR also includes code to handle generics, unlike the original PR, since doing so influenced the design of the original PR significantly.

r? Kobzol

Tracking issue: rust-lang#129107
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 5, 2024
Implement struct_target_features.

This PR implements a first version of RFC 3525.

This is a roll-up of rust-lang#129764, rust-lang#129783 and rust-lang#129764, which will hopefully result in a PR that does not introduce perf regressions in the first place.

This PR also includes code to handle generics, unlike the original PR, since doing so influenced the design of the original PR significantly.

r? Kobzol

Tracking issue: rust-lang#129107
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-experimental Blocker: In-tree experiment; RFC pending or unneeded. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-struct_target_features `#![feature(struct_target_features)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants