-
Notifications
You must be signed in to change notification settings - Fork 13k
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
How should cfg(target-feature) behave around forbidden target features? #132351
Comments
My current plan is to have a representation like this: pub enum Stability {
/// This target feature is stable. It can be used in `#[cfg(target_feature)]` and
/// `allow_toggle` controls when it can be used in `#[target_feature]` or
/// `-Ctarget-feature`.
Stable {
allow_toggle: fn(&Session) -> Result<(), &'static str>,
},
/// This target feature is unstable. It can be used in `#[cfg(target_feature)]` on nightly,
/// and `allow_toggle` controls when it can be used in `#[target_feature]` or
/// `-Ctarget-feature`; the former additionally requires enabling the given nightly feature.
Unstable {
feature: Symbol,
allow_toggle: fn(&Session) -> Result<(), &'static str>,
},
/// This feature can not be set via `-Ctarget-feature` or `#[target_feature]`, it can only be set in the basic
/// target definition. Used in particular for features that change the floating-point ABI.
Forbidden { reason: &'static str },
} For instance, What I am not sure about is whether a query can return function pointers. Also it may be good to evaluate those functions only once... but we actually do access this target feature stuff without going through the query in a bunch of early codegen setup code. We'll just have to benchmark this. |
…ingjubilee forbid toggling x87 and fpregs on hard-float targets Part of rust-lang/rust#116344, follow-up to rust-lang/rust#129884: The `x87` target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](rust-lang/rust#130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86). Also fixes rust-lang/rust#132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature. The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure. r? `@workingjubilee`
…ingjubilee forbid toggling x87 and fpregs on hard-float targets Part of rust-lang/rust#116344, follow-up to rust-lang/rust#129884: The `x87` target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](rust-lang/rust#130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86). Also fixes rust-lang/rust#132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature. The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure. r? `@workingjubilee`
…ingjubilee forbid toggling x87 and fpregs on hard-float targets Part of rust-lang/rust#116344, follow-up to rust-lang/rust#129884: The `x87` target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](rust-lang/rust#130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86). Also fixes rust-lang/rust#132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature. The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure. r? `@workingjubilee`
See #129884 and #116344 for context explaining what a forbidden target feature is.
The plan for target features like
fpreg
on ARM is that they will be forbidden unless the target hassoft-float
in its base feature set. This means our hardfloat ARM targets requirefpregs
, but on our softfloat ARM targets users can opt-in to having the FPU avialable, it just won't be used for the ABI. See #124404 for why we can't just forbidfpregs
outright.What should the behavior of
cfg(target-feature = "fpregs")
be, then? For now, #129884 makes it so that forbidden features are never set incfg
. But for this one it seems like when we unstable addfpregs
for softfloat targets, then we'll want to unstably expose the ability to docfg(target-feature = "fpregs")
on all ARM targets. So we'll need a concept of target features that are forbidden to set, but can be unstably (and eventually, stably) queried. At the same time, other target features likesoft-float
likely should never be queried.So seems like for these more complicated features, the question whether a feature is forbidden to set is somewhat orthogonal to its stability. I have some plans for a follow-up PR to #129884 to be able to represent that, but still need to figure out the details.
The text was updated successfully, but these errors were encountered: