Many Arm microcontoller target feature flags are missing

[thejpster]

@RalfJung asked me to open an issue listing all the useful Arm microcontroller feature flags that are currently entirely unsupported by Rust, not even unstably.

These are all listed at https://doc.rust-lang.org/nightly/rustc/platform-support/arm-none-eabi.html and the sub-pages, as modified by #130987.

Selecting a CPU with -C target-cpu=xxx causes LLVM to enable all the optional features of that type of CPU. However, sometimes CPUs are sold without certain features (e.g. you can get a Cortex-M4 either with or without an FPU). So, we use these -C target-feature=... flags to disable some of the things that LLVM over-enthusiastically enabled for us when we selected a target-cpu. If you don't select a target-cpu, you don't need these flags because by default, only the architecture's baseline features are enabled and you never want to turn those off.

• -fpregs - don't emit FPU instructions
• -fp64 - don't emit double precision FPU instructions
• -mve - don't emit Float or Integer M-Profile Vector Extension instructions
• -mve.fp - don't emit Float M-Profile Vector Extension instructions
• -dsp - don't emit DSP instructions
• +mve - do emit Integer M-Profile Vector Extension instructions (used with -fpregs because MVE uses registers shared with the FPU and those registers are present if you have Integer MVE but no FPU)

These are alongside the following target CPUs (-C target-cpu=...):

• cortex-m0
• cortex-m0plus
• cortex-m3
• cortex-m4
• cortex-m7
• cortex-m33
• cortex-m35p
• cortex-m55
• cortex-m85

If you don't want to use -C target-cpu... then the following additional flags can enable certain features. However, these aren't currently mentioned in the documentation (except +mve because it's listed above).

• +mve - M-Profile Vector Extensions (integer)
• +mve.fp - M-Profile Vector Extensions (floating point)
• +dsp - DSP extensions
• +fp-armv8d16sp - single precision FPU for Armv8-M
• +fp-armv8d16 - double precision FPU for Armv8-M
• +vfp4d16sp - single precision FPU for Armv7E-M
• +vfp4d16 - double precision FPU for Armv7E-M

[thejpster]

I find this example code useful in Godbolt for checking what the flags do and don't do:

#![no_std]

#[no_mangle]
pub fn f32_add(x: [f32; 4], y: [f32; 4]) -> [f32; 4] {
    [
        (x[0] * 2.0) + y[0],
        (x[1] * 2.0) + y[1],
        (x[2] * 2.0) + y[2],
        (x[3] * 2.0) + y[3],
    ]
}

#[no_mangle]
pub fn f64_add(x: [f64; 4], y: [f64; 4]) -> [f64; 4] {
    [
        (x[0] * 2.0) + y[0],
        (x[1] * 2.0) + y[1],
        (x[2] * 2.0) + y[2],
        (x[3] * 2.0) + y[3],
    ]
}

#[no_mangle]
pub fn i32_add(x: [i32; 4], y: [i32; 4]) -> [i32; 4] {
    [
        (x[0] * 2) + y[0],
        (x[1] * 2) + y[1],
        (x[2] * 2) + y[2],
        (x[3] * 2) + y[3],
    ]
}

At opt-level=3 it will auto-vectorise on CPUs with MVE support.

[RalfJung]

Cc @rust-lang/compiler
(not sure which team is mainly in charge of target features, t-compiler or t-lang?)

None of these features are currently listed as known ARM features in rustc, so they all cause a warning. And yet our docs recommend people to use them. So that's clearly not great.

fpregs is particularly tricky since disabling it on an eabihf target is unsound as it changes the float ABI. On eabi targets it's fine because those have +soft-float anyway, which forces the soft-float ABI. So we'll need to stabilize this in a way where particular targets opt-in to supporting this feature, or something like that.

[jieyouxu]

Nominating for T-compiler triage meeting next week.

cc https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/stabilizing.20compiler.20flags.20for.20Rust-for-Linux. T-compiler probably wants to have a dedicated design meeting for target-features, target-cpu, target specs and how they are tracked in a dep graph.

[RalfJung]

The avx512 mess would also fall in that general category (but is off-topic here).

EDIT: and #131058, as well.

[thejpster]

I wrote up a blog looking into what some of these flags do - https://www.thejpster.org.uk/blog/blog-2024-09-29/.

[apiraino]

T-compiler visited this during the triage meeting, will probably need a design meeting (about the recent discussions around target-feature and ABI).

@rustbot label -I-compiler-nominated

[thejpster]

I learned about do-while-loop-with-tail-predication and was so impressed I wrote up a second blog post: https://thejpster.org.uk/blog/blog-2024-10-03/

You really want compiler-builtin's memcpy and memset compiled with MVE, if you possibly can.