Warn if feature settings may break compilation

[workingjubilee]

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:

• Enabling soft floats and not disabling SSE/SSE2 and the x87 FPU. This came up with LLVM ERROR: Do not know how to split this operator's operand! #61721
• "-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! #61721
• Enabling SSE or SSE2 for single functions on x86-without-SSE2 platforms and calling into it and returning the float. See -C target-feature/-C target-cpu are unsound #64609 for more.

Some 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.

[workingjubilee]

This requires digging deep into the target_feature code and likely refactoring it. Much of it lives in https://github.com/rust-lang/rust/tree/master/compiler/rustc_codegen_llvm, most particularly this file, which handles things like the interface to LLVM's target features:
https://github.com/rust-lang/rust/blob/master/compiler/rustc_codegen_llvm/src/llvm_util.rs
Especially this:

rust/compiler/rustc_codegen_llvm/src/llvm_util.rs

Lines 324 to 332 in 0fb1c37

	/// The list of LLVM features computed from CLI flags (`-Ctarget-cpu`, `-Ctarget-feature`,
	/// `--target` and similar).
	// FIXME(nagisa): Cache the output of this somehow? Maybe make this a query? We're calling this
	// for every function that has `#[target_feature]` on it. The global features won't change between
	// the functions; only crates, maybe…
	pub fn llvm_global_features(sess: &Session) -> Vec<String> {
	// FIXME(nagisa): this should definitely be available more centrally and to other codegen backends.
	/// These features control behaviour of rustc rather than llvm.
	const RUSTC_SPECIFIC_FEATURES: &[&str] = &["crt-static"];

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

	/// Composite function which sets LLVM attributes for function depending on its AST (`#[attribute]`)
	/// attributes.
	pub fn from_fn_attrs(cx: &CodegenCx<'ll, 'tcx>, llfn: &'ll Value, instance: ty::Instance<'tcx>) {

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.

[Wardenfar]

Hello @workingjubilee,

I'm trying to understand the issue and i have some questions.

• For the first sub-task : i need to detect imcompatible global features or at function level ?
  and i have not found a way to detect x87 FPU.
• To report an error : should i use sess.err(...) ?

Thanks

[bstrie]

@Wardenfar You may want to try asking on the #t-compiler Zulip channel: https://rust-lang.zulipchat.com/#streams/131828/t-compiler

[workingjubilee]

My apologies for taking so long to answer. Yes, I am more reachable on Zulip.

1. • Q: Should we detect incompatible features at the global feature level?
   • A: Yes, definitely.
2. • Q: Should we detect incompatible features at the function feature level?
   • A: Ideally also yes.
3. • Q. How is the x87 FPU denoted?
   • A. The x87 FPU feature uses the string "+x87" to enable and "-x87" to disable
4. • Q. How to report an error?
   • A. Yes, sess.err or any of the other typical error emitters should be fine, including builders like struct_span_err.

[workingjubilee]

this is turning out to be way more complex than I thought it would possibly be, see:

• Figure out which target features affect float ABI #131799

[RalfJung]

This is fully subsumed by #116344 and #116558, isn't it?

[RalfJung]

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.