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

rustc: Support Rust-specific features in -Ctarget-feature #84991

Merged
merged 1 commit into from
May 7, 2021

Conversation

alexcrichton
Copy link
Member

Since the beginning of time the -Ctarget-feature flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
#[target_feature] attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:

#[target_feature(enable = "pclmulqdq")]
unsafe fn foo() {
    // ...
}

but on the command line you would write:

RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release

This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like WebAssembly
SIMD
which may be more
prevalent.

This commit implements a mapping to translate requests via
-Ctarget-feature through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
+pclmulqdq will work on x86 targets where as previously it did not.

I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
-Ctarget-feature, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.

Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:

    #[target_feature(enable = "pclmulqdq")]
    unsafe fn foo() {
        // ...
    }

but on the command line you would write:

    RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release

This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](rust-lang#74372) which may be more
prevalent.

This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.

I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
@rust-highfive
Copy link
Collaborator

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 6, 2021
@petrochenkov
Copy link
Contributor

r? @nagisa (as the author of #83084)

@rust-highfive rust-highfive assigned nagisa and unassigned matthewjasper May 6, 2021
Copy link
Member

@nagisa nagisa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@bors r+

I would like to see us moving to warn against and deprecate LLVM-specific names for the flag in the future. I guess I'll file an issue.

let feature = if s.starts_with("+") || s.starts_with("-") {
&s[1..]
} else {
return Some(s.to_string());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious that we accept target features without a leading + without complaining (like we'd otherwise do for unknown features), but they don't have any particular effect, either.

@nagisa
Copy link
Member

nagisa commented May 6, 2021

@bors r+

@bors
Copy link
Contributor

bors commented May 6, 2021

📌 Commit 97658e5 has been approved by nagisa

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 6, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 7, 2021
…r=nagisa

rustc: Support Rust-specific features in -Ctarget-feature

Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:

    #[target_feature(enable = "pclmulqdq")]
    unsafe fn foo() {
        // ...
    }

but on the command line you would write:

    RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release

This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](rust-lang#74372) which may be more
prevalent.

This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.

I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 7, 2021
…r=nagisa

rustc: Support Rust-specific features in -Ctarget-feature

Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:

    #[target_feature(enable = "pclmulqdq")]
    unsafe fn foo() {
        // ...
    }

but on the command line you would write:

    RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release

This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](rust-lang#74372) which may be more
prevalent.

This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.

I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
bors added a commit to rust-lang-ci/rust that referenced this pull request May 7, 2021
Rollup of 9 pull requests

Successful merges:

 - rust-lang#84254 (illumos should put libc last in library search order)
 - rust-lang#84442 (Unify rustc and rustdoc parsing of `cfg()`)
 - rust-lang#84655 (Cleanup of `wasm`)
 - rust-lang#84866 (linker: Avoid library duplication with `/WHOLEARCHIVE`)
 - rust-lang#84930 (rename LLVM target for RustyHermit)
 - rust-lang#84991 (rustc: Support Rust-specific features in -Ctarget-feature)
 - rust-lang#85029 (SGX mutex is movable)
 - rust-lang#85030 (Rearrange SGX split module files)
 - rust-lang#85033 (some further small cleanups)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit a3fbde4 into rust-lang:master May 7, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants