mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
46ddf460af
rust/tests/codegen/target-feature-overrides.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

48 lines
1.2 KiB
Rust
Raw Normal View History

Adjust `-Ctarget-cpu=native` handling in cg_llvm When cg_llvm encounters the `-Ctarget-cpu=native` it computes an explciit set of features that applies to the target in order to correctly compile code for the host CPU (because e.g. `skylake` alone is not sufficient to tell if some of the instructions are available or not). However there were a couple of issues with how we did this. Firstly, the order in which features were overriden wasn't quite right – conceptually you'd expect `-Ctarget-cpu=native` option to override the features that are implicitly set by the target definition. However due to how other `-Ctarget-cpu` values are handled we must adopt the following order of priority: * Features from -Ctarget-cpu=*; are overriden by * Features implied by --target; are overriden by * Features from -Ctarget-feature; are overriden by * function specific features. Another problem was in that the function level `target-features` attribute would overwrite the entire set of the globally enabled features, rather than just the features the `#[target_feature(enable/disable)]` specified. With something like `-Ctarget-cpu=native` we'd end up in a situation wherein a function without `#[target_feature(enable)]` annotation would have a broader set of features compared to a function with one such attribute. This turned out to be a cause of heavy run-time regressions in some code using these function-level attributes in conjunction with `-Ctarget-cpu=native`, for example. With this PR rustc is more careful about specifying the entire set of features for functions that use `#[target_feature(enable/disable)]` or `#[instruction_set]` attributes. Sadly testing the original reproducer for this behaviour is quite impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in particular on developer or CI machines.
2021-03-13 07:29:39 -06:00
// revisions: COMPAT INCOMPAT
// needs-llvm-components: x86
// compile-flags: --target=x86_64-unknown-linux-gnu -Copt-level=3
// [COMPAT] compile-flags: -Ctarget-feature=+avx2,+avx
// [INCOMPAT] compile-flags: -Ctarget-feature=-avx2,-avx
Change `src/test` to `tests` in source files, fix tidy and tests
2023-01-05 02:45:44 -06:00
// See also tests/assembly/target-feature-multiple.rs
Adjust `-Ctarget-cpu=native` handling in cg_llvm When cg_llvm encounters the `-Ctarget-cpu=native` it computes an explciit set of features that applies to the target in order to correctly compile code for the host CPU (because e.g. `skylake` alone is not sufficient to tell if some of the instructions are available or not). However there were a couple of issues with how we did this. Firstly, the order in which features were overriden wasn't quite right – conceptually you'd expect `-Ctarget-cpu=native` option to override the features that are implicitly set by the target definition. However due to how other `-Ctarget-cpu` values are handled we must adopt the following order of priority: * Features from -Ctarget-cpu=*; are overriden by * Features implied by --target; are overriden by * Features from -Ctarget-feature; are overriden by * function specific features. Another problem was in that the function level `target-features` attribute would overwrite the entire set of the globally enabled features, rather than just the features the `#[target_feature(enable/disable)]` specified. With something like `-Ctarget-cpu=native` we'd end up in a situation wherein a function without `#[target_feature(enable)]` annotation would have a broader set of features compared to a function with one such attribute. This turned out to be a cause of heavy run-time regressions in some code using these function-level attributes in conjunction with `-Ctarget-cpu=native`, for example. With this PR rustc is more careful about specifying the entire set of features for functions that use `#[target_feature(enable/disable)]` or `#[instruction_set]` attributes. Sadly testing the original reproducer for this behaviour is quite impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in particular on developer or CI machines.
2021-03-13 07:29:39 -06:00
#![feature(no_core, lang_items)]
#![crate_type = "lib"]
#![no_core]
#[lang = "sized"]
trait Sized {}
#[lang = "copy"]
trait Copy {}
extern "C" {
fn peach() -> u32;
}
#[inline]
#[target_feature(enable = "avx")]
#[no_mangle]
pub unsafe fn apple() -> u32 {
// CHECK-LABEL: @apple()
// CHECK-SAME: [[APPLEATTRS:#[0-9]+]] {
// CHECK: {{.*}}call{{.*}}@peach
peach()
}
Always include global target features in function attributes This ensures that information about target features configured with `-C target-feature=...` or detected with `-C target-cpu=native` is retained for subsequent consumers of LLVM bitcode. This is crucial for linker plugin LTO, since this information is not conveyed to the plugin otherwise.
2022-03-02 18:00:00 -06:00
// target features same as global
Adjust `-Ctarget-cpu=native` handling in cg_llvm When cg_llvm encounters the `-Ctarget-cpu=native` it computes an explciit set of features that applies to the target in order to correctly compile code for the host CPU (because e.g. `skylake` alone is not sufficient to tell if some of the instructions are available or not). However there were a couple of issues with how we did this. Firstly, the order in which features were overriden wasn't quite right – conceptually you'd expect `-Ctarget-cpu=native` option to override the features that are implicitly set by the target definition. However due to how other `-Ctarget-cpu` values are handled we must adopt the following order of priority: * Features from -Ctarget-cpu=*; are overriden by * Features implied by --target; are overriden by * Features from -Ctarget-feature; are overriden by * function specific features. Another problem was in that the function level `target-features` attribute would overwrite the entire set of the globally enabled features, rather than just the features the `#[target_feature(enable/disable)]` specified. With something like `-Ctarget-cpu=native` we'd end up in a situation wherein a function without `#[target_feature(enable)]` annotation would have a broader set of features compared to a function with one such attribute. This turned out to be a cause of heavy run-time regressions in some code using these function-level attributes in conjunction with `-Ctarget-cpu=native`, for example. With this PR rustc is more careful about specifying the entire set of features for functions that use `#[target_feature(enable/disable)]` or `#[instruction_set]` attributes. Sadly testing the original reproducer for this behaviour is quite impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in particular on developer or CI machines.
2021-03-13 07:29:39 -06:00
#[no_mangle]
pub unsafe fn banana() -> u32 {
// CHECK-LABEL: @banana()
// CHECK-SAME: [[BANANAATTRS:#[0-9]+]] {
// COMPAT: {{.*}}call{{.*}}@peach
// INCOMPAT: {{.*}}call{{.*}}@apple
apple() // Compatible for inline in COMPAT revision and can't be inlined in INCOMPAT
}
// CHECK: attributes [[APPLEATTRS]]
// COMPAT-SAME: "target-features"="+avx2,+avx,+avx"
// INCOMPAT-SAME: "target-features"="-avx2,-avx,+avx"
// CHECK: attributes [[BANANAATTRS]]
Always include global target features in function attributes This ensures that information about target features configured with `-C target-feature=...` or detected with `-C target-cpu=native` is retained for subsequent consumers of LLVM bitcode. This is crucial for linker plugin LTO, since this information is not conveyed to the plugin otherwise.
2022-03-02 18:00:00 -06:00
// COMPAT-SAME: "target-features"="+avx2,+avx"
// INCOMPAT-SAME: "target-features"="-avx2,-avx"
Reference in New Issue Copy Permalink