-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Should -Ctarget-feature go straight to LLVM? #49653
Comments
So in RFC2045 which #44839 tracks the consensus was basically the following:
So in the RFC everybody agreed that while this is the case users don't care: this would be a breaking change in the API of rustc, RUSTFLAGS , and some scripts that rely on this would need to be updated. Everybody agreed that the "defacto stabilization" of So that was all that I can recall. Personally, I still think that the plan sketched in the RFC isn't that bad. I dislike having two ways to enable target features on nightly, and I dislike the naming a bit, but at least on nightly being able to bypass rustc's whitelist still feels necessary to me. Maybe If we are going to rename things, we should probably do so before stabilizing |
How is removing the flag entirely from stable compilers less of a compatibility break than removing some of the less commonly used values that can be passed to it today? |
I have more sympathy for killing the Edit: to be clear, I believe if we can get away with making -C target-feature nightly-only, we can just as well remove it entirely. |
It isn't and I think that is an alternative worth considering. We could keep
Sometimes when targeting arm, mips, and powerpc, where not that many features are whitelisted, it was useful to be able to play with all the features that LLVM supports. For enabling simd on these platforms one feature is rarely enough (one might need to enable floating-point support + simd, for example). Having said this, with time all these features will be whitelisted. Also, modifying the whitelist is pretty trivial. I would prefer if we would support a way of passing LLVM features directly on nightly for experimentation purposes, but I don't have strong feelings about this. @japaric does |
Is that really true? I think the change I made to
On that note, we also support |
Oh duh you're right, the string is passed directly to LLVM. Its effect on cfgs and the like varies by linked LLVM version though, so there's still a problem (not to mention the other source of instability, LLVM changing its definition of the feature).
If we keep having such an option, I'd prefer to call it |
I feel the same as @gnzlbg I think in this regard. I think we should add |
Does |
@cuviper AFAIK yeah, we pass that straight to LLVM and don't really have any practical stability guarantees there |
@cuviper Yes, but since it doesn't have a whitelisted counterpart (attributes or whatever) like target features have, there's no inconsistency, just yet another option that appears stable but actually isn't, so I wouldn't count it under this issue specifically. |
On one hand, it would be weird to require nightly Rust to be able to specify the target cpu. On the other, I don't see how we can guarantee that we will always support some cpu for any backend whatsoever. |
Triage: not aware of any changes here, the problem is still the same. |
@steveklabnik we don't have a label for accidental stabilizations, which makes them hard to find (there are a couple of accidental stabilizations issues opened). It might make sense to create a label for it and start using it. cc @jonas-schievink |
There's |
One thing which would help would be to separate I'll see if I can implement that. |
cc #44815 ("rustc silently ignores invalid -C target-feature names") |
…ments, r=petrochenkov Categorize and explain target features support There are 3 different uses of the `-C target-feature` args passed to rustc: 1. All of the features are passed to LLVM, which uses them to configure code-generation. This is sort-of stabilized since 1.0 though LLVM does change/add/remove target features regularly. 2. Target features which are in [the compiler's allowlist](https://github.com/rust-lang/rust/blob/69e1d22ddbc67b25141a735a22a8895a678b32ca/compiler/rustc_codegen_ssa/src/target_features.rs#L12-L34) can be used in `cfg!(target_feature)` etc. These may have different names than in LLVM and are renamed before passing them to LLVM. 3. Target features which are in the allowlist and which are stabilized or feature-gate-enabled can be used in `#[target_feature]`. It can be confusing that `rustc --print target-features` just prints out the LLVM features without separating out the rustc features or even mentioning that the dichotomy exists. This improves the situation by separating out the rustc and LLVM target features and adding a brief explanation about the difference. Abbreviated Example Output: ``` $ rustc --print target-features Features supported by rustc for this target: adx - Support ADX instructions. aes - Enable AES instructions. ... xsaves - Support xsaves instructions. crt-static - Enables libraries with C Run-time Libraries(CRT) to be statically linked. Code-generation features supported by LLVM for this target: 16bit-mode - 16-bit mode (i8086). 32bit-mode - 32-bit mode (80386). ... x87 - Enable X87 float instructions. xop - Enable XOP instructions. Use +feature to enable a feature, or -feature to disable it. For example, rustc -C target-cpu=mycpu -C target-feature=+feature1,-feature2 Code-generation features cannot be used in cfg or #[target_feature], and may be renamed or removed in a future version of LLVM or rustc. ``` Motivated by rust-lang#83975. CC rust-lang#49653
The
--print target-features
and-C target-feature
options list/accept all target features LLVM knows, under the names LLVM gives them (see discussion in #49428). This is in contrast to#[target_feature]
andcfg(target_feature)
, which accept only explicitly whitelisted features, and in some cases change the LLVM names (e.g.,bmi1
instead ofbmi
). This is inconsistent, and also makes the command line interface less stable than it could be.As @gnzlbg noted in #49428, this difference has existed for a while. However, in effect the command line options don't have a real stability guarantee:
rustc
s not built with our LLVM fork don't currently recognize any target features, and the LLVM names can change under our feet (this was part of the rationale for having a whitelist in rustc). Note that-C
flags "without stability guarantee" are not without precedent, e.g., consider-C passes
(which also depends on LLVM internals).So I believe we're within our rights to change this. Especially now that the whitelist is much more complete. And it has real advantages: consistency between command line and attributes/cfgs, more stability for the command line switch, and making it work on
rustc
s with system LLVMs, thanks to @cuviper's work in #49428.cc @japaric are you aware of uses of this option that aren't covered by the current whitelists?
The text was updated successfully, but these errors were encountered: