-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Remove ability to disable some target features #116584
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -459,23 +459,25 @@ pub(crate) fn global_llvm_features(sess: &Session, diagnostics: bool) -> Vec<Str | |
// Features that come earlier are overridden by conflicting features later in the string. | ||
// Typically we'll want more explicit settings to override the implicit ones, so: | ||
// | ||
// * Features disabled by --target; are overridden by | ||
// * Features from -Ctarget-cpu=*; are overridden by [^1] | ||
// * Features implied by --target; are overridden by | ||
// * Features from -Ctarget-feature; are overridden by | ||
// * Features implied by --target; are overridden by | ||
// * function specific features. | ||
// | ||
// [^1]: target-cpu=native is handled here, other target-cpu values are handled implicitly | ||
// through LLVM TargetMachine implementation. | ||
// | ||
// FIXME(nagisa): it isn't clear what's the best interaction between features implied by | ||
// `-Ctarget-cpu` and `--target` are. On one hand, you'd expect CLI arguments to always | ||
// override anything that's implicit, so e.g. when there's no `--target` flag, features implied | ||
// the host target are overridden by `-Ctarget-cpu=*`. On the other hand, what about when both | ||
// `--target` and `-Ctarget-cpu=*` are specified? Both then imply some target features and both | ||
// flags are specified by the user on the CLI. It isn't as clear-cut which order of precedence | ||
// should be taken in cases like these. | ||
let mut features = vec![]; | ||
|
||
// Features disabled by an implicit or explicit `--target`. | ||
features.extend( | ||
sess.target | ||
.features | ||
.split(',') | ||
.filter(|v| !v.is_empty() && backend_feature_name(v).is_some() && v.starts_with("-")) | ||
.map(String::from), | ||
); | ||
|
||
// -Ctarget-cpu=native | ||
match sess.opts.cg.target_cpu { | ||
Some(ref s) if s == "native" => { | ||
|
@@ -501,15 +503,6 @@ pub(crate) fn global_llvm_features(sess: &Session, diagnostics: bool) -> Vec<Str | |
Some(_) | None => {} | ||
}; | ||
|
||
// Features implied by an implicit or explicit `--target`. | ||
features.extend( | ||
sess.target | ||
.features | ||
.split(',') | ||
.filter(|v| !v.is_empty() && backend_feature_name(v).is_some()) | ||
.map(String::from), | ||
); | ||
|
||
// -Ctarget-features | ||
let supported_features = supported_target_features(sess); | ||
let mut featsmap = FxHashMap::default(); | ||
|
@@ -583,6 +576,15 @@ pub(crate) fn global_llvm_features(sess: &Session, diagnostics: bool) -> Vec<Str | |
.flatten(); | ||
features.extend(feats); | ||
|
||
// Features implied by an implicit or explicit `--target`. | ||
features.extend( | ||
sess.target | ||
.features | ||
.split(',') | ||
.filter(|v| !v.is_empty() && backend_feature_name(v).is_some() && v.starts_with("+")) | ||
.map(String::from), | ||
); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So this will silently ignore I think we'll want to compare that in the final feature set, certain features (for x86: x87, soft-float; for other targets we need to still determine this list) have the same state as without applying the user config. This needs to take into account |
||
|
||
if diagnostics && let Some(f) = check_tied_features(sess, &featsmap) { | ||
sess.emit_err(TargetFeatureDisableOrEnable { | ||
features: f, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t believe this change addresses this FIXME at all. It still isn’t at all clear to me, even if we agreed that we don’t want to allow some features to be configurable outside of
--target
specifications, that this specific way to build up the feature set is the absolutely the correct one.For example:
pretty clearly shows that the intent is for the
-Ctarget-cpu=native
to take precedence over whateverx86_64-unknown-linux-gnu
means (including it not having any of the fancy AVX extensions.)On the other hand
is quite a bit more ambiguous: does the user want something that would run on a pentium4? Or something that would run on an x86_64v4 class hardware, which pentium4 is not? Should the ordering of flags be taken into the account (unusual for rustc, but standard behaviour in gcc/clang style CLIs.) Perhaps it would be better to just error outright?