rust/compiler/rustc_codegen_llvm/src
Dylan DPC 67d6cc6ef3
Rollup merge of #91608 - workingjubilee:fold-neon-fp, r=nagisa,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 https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.

- Fixes rust-lang/rust#95002.
- Fixes rust-lang/rust#95064.
- Fixes rust-lang/rust#95122.
2022-03-23 03:05:28 +01:00
..
back Improved error message for failed bitcode load 2022-03-06 15:25:05 +01:00
coverageinfo add #[rustc_pass_by_value] to more types 2022-03-08 15:39:52 +01:00
debuginfo debuginfo: Refactor debuginfo generation for types -- Rename DebugInfoMethods::create_vtable_metadata() to DebugInfoMethods::create_vtable_debuginfo() 2022-03-14 17:25:24 +01:00
llvm Auto merge of #94539 - tmiasko:string-attributes, r=nikic 2022-03-04 10:38:11 +00:00
abi.rs Pass LLVM string attributes as string slices 2022-03-03 00:28:50 +01:00
allocator.rs Auto merge of #88098 - Amanieu:oom_panic, r=nagisa 2022-03-18 03:01:46 +00:00
asm.rs Add LLVM attributes in batches instead of individually 2022-02-26 13:14:55 -05:00
attributes.rs Always include global target features in function attributes 2022-03-04 16:57:34 +01:00
base.rs Add LLVM attributes in batches instead of individually 2022-02-26 13:14:55 -05:00
builder.rs Auto merge of #94159 - erikdesjardins:align-load, r=nikic 2022-03-04 08:14:31 +00:00
callee.rs Remove in_band_lifetimes from rustc_codegen_llvm 2021-12-16 14:43:32 -05:00
common.rs Auto merge of #94638 - erikdesjardins:noextranull, r=nagisa 2022-03-07 02:07:36 +00:00
consts.rs debuginfo: Refactor debuginfo generation for types 2022-03-14 16:49:06 +01:00
context.rs debuginfo: Refactor debuginfo generation for types 2022-03-14 16:49:06 +01:00
declare.rs Remove LLVM attribute removal 2022-02-28 00:02:11 -05:00
intrinsic.rs Clarify Layout interning. 2022-03-07 13:41:47 +11:00
lib.rs rename ErrorReported -> ErrorGuaranteed 2022-03-02 09:45:25 -06:00
llvm_util.rs Filter for all features instead of any 2022-03-22 15:20:01 -07:00
mono_item.rs Remove in_band_lifetimes from rustc_codegen_llvm 2021-12-16 14:43:32 -05:00
type_.rs Remove in_band_lifetimes from rustc_codegen_llvm 2021-12-16 14:43:32 -05:00
type_of.rs Improve AdtDef interning. 2022-03-11 13:31:24 +11:00
va_arg.rs Introduce Bx::switch_to_block 2022-02-24 12:18:21 +01:00
value.rs mv compiler to compiler/ 2020-08-30 18:45:07 +03:00