-
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
Warn if feature settings may break compilation #89586
Comments
This requires digging deep into the rust/compiler/rustc_codegen_llvm/src/llvm_util.rs Lines 324 to 332 in 0fb1c37
And this related function may also need to be reviewed, as it handles function-level setting of codegen features, like with #[target_feature] :rust/compiler/rustc_codegen_llvm/src/attributes.rs Lines 227 to 229 in 0fb1c37
And at least some of this logic should probably be, as part of this, hoisted into https://github.com/rust-lang/rust/tree/master/compiler/rustc_codegen_ssa. Accordingly, while it is a scoped piece of work, it is not a trivial task either. |
Hello @workingjubilee, I'm trying to understand the issue and i have some questions.
Thanks |
@Wardenfar You may want to try asking on the #t-compiler Zulip channel: https://rust-lang.zulipchat.com/#streams/131828/t-compiler |
My apologies for taking so long to answer. Yes, I am more reachable on Zulip.
|
Fold aarch64 feature +fp into +neon Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64: The Neon unit, which handles both floating point and SIMD instructions. Moreover, a configuration for AArch64 must include both or neither. Arm says "entirely proprietary" toolchains may omit floating point: https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point In the Programmer's Guide for Armv8-A, Arm says AArch64 can have both FP and Neon or neither in custom implementations: https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON In "Bare metal boot code for Armv8-A", enabling Neon and FP is just disabling the same trap flag: https://developer.arm.com/documentation/dai0527/a In an unlikely future where "Neon and FP" become unrelated, we can add "[+-]fp" as its own feature flag. Until then, we can simplify programming with Rust on AArch64 by folding both into "[+-]neon", which is valid as it supersets both. "[+-]neon" is retained for niche uses such as firmware, kernels, "I just hate floats", and so on. I am... pretty sure no one is relying on this. An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see rust-lang#89586. And per the above notes, plus the discussion in rust-lang#86941, there should be no real use cases for leaving these features split: the two should in fact always go together. Fixes rust-lang#95002. Fixes rust-lang#95122.
…sa,Amanieu Fold aarch64 feature +fp into +neon Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64: The Neon unit, which handles both floating point and SIMD instructions. Moreover, a configuration for AArch64 must include both or neither. Arm says "entirely proprietary" toolchains may omit floating point: https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point In the Programmer's Guide for Armv8-A, Arm says AArch64 can have both FP and Neon or neither in custom implementations: https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON In "Bare metal boot code for Armv8-A", enabling Neon and FP is just disabling the same trap flag: https://developer.arm.com/documentation/dai0527/a In an unlikely future where "Neon and FP" become unrelated, we can add "[+-]fp" as its own feature flag. Until then, we can simplify programming with Rust on AArch64 by folding both into "[+-]neon", which is valid as it supersets both. "[+-]neon" is retained for niche uses such as firmware, kernels, "I just hate floats", and so on. I am... pretty sure no one is relying on this. An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see rust-lang#89586. And per the above notes, plus the discussion in rust-lang#86941, there should be no real use cases for leaving these features split: the two should in fact always go together. - Fixes rust-lang#95002. - Fixes rust-lang#95064. - Fixes rust-lang#95122.
this is turning out to be way more complex than I thought it would possibly be, see: |
Oh damnit, I don't know what happened with the labels... I just added ABI and target-feature, and then github removed all the others. Not sure why. |
Currently, if a user instructs the compiler to adjust the features for compilation, or uses
#[target_feature]
to set unusual feature settings for a function, or introduces a custom target, this can trigger miscompilations if the settings are improperly "aligned" with each other (to do correct parameter passing and so on). This mostly impacts x86, due to its particular architectural extensions, but it could affect other platforms.Some examples we definitely want to warn on:
"-sse"
but not"-sse2"
for x86-64. I don't know how this even makes sense, honestly, but it also came up with LLVM ERROR: Do not know how to split this operator's operand! #61721Some of these issues are currently caught by LLVM, but Rust programmers often find underlying LLVM errors surfacing to be mysterious and cryptic, and in this case we can definitely detect them and warn about them ourselves.
In addition, due to the desire for binary floating point conformance per #10087, we probably want to emit a warning for any build configuration such that, despite having an FPU we consider to be conformant and desirable, disables the ability to use such a floating point unit, such that it could introduce non-conformant floating point code. However, that can be extended into a future issue when all the known-100%-bad bases are covered.
The text was updated successfully, but these errors were encountered: