03:00 <wyager[m]> What's the story with double-precision floating point on ARM? I'm using an STM32H747, which according to the datasheet supports double precision. I have some code using f64, but grepping the generated assembly, I see a lot of instructions like vmul.f32 but no vmul.f64. Do I have to tell rustc to set the FPU to FPv5-DP-D16-M or something?

03:03 <adamgreig[m]> yes, pass -C target-feature=+fp64 or -C target-cpu=cortex-m7

03:31 <wyager[m]> <adamgreig[m]> "yes, pass -C target-feature=+fp..." <- Thank you. It looks like the `+fp64` is necessary. Just specifying m7 doesn't do it. Interestingly, something complains "warning: unknown and unstable feature specified for `-Ctarget-feature`: `fp64`", but it looks like the generated assembly contains these instructions now

10:31 <thejpster[m]> I think non fpu, single or single+double fp is a configuration option when you licence the core from arm

10:31 <thejpster[m]> https://developer.arm.com/Processors/Cortex-M7#Technical-Specifications

10:32 <thejpster[m]> We only have soft and hard float ABI as targets, and we just assume if you want soft float you have no fpu and if you want hard float you have the single precision fpu.

12:16 <M9names[m]> the quartiq folks used a different feature. +fp64 looks like it selects vfp2, where +fp-armv8d16 selects vfp5 with double precision and +fp-armv8d16sp is the single precision option.

12:16 <M9names[m]> https://github.com/quartiq/thermostat-eem/commit/14a4a0306d103199b9b7f3f19bfb044f0ffb2273

12:17 <M9names[m]> source https://llvm.org/doxygen/ARMTargetParser_8cpp_source.html

13:05 <adamgreig[m]> this keeps coming up it seems! the rust target file talks about +fp64 here, https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/targets/thumbv7em_none_eabihf.rs#L9

13:05 <adamgreig[m]> we wrote a new target support file here that taks about fp64 and cortex-m7 https://github.com/adamgreig/rust/blob/7cfb29878a24928ee47e48ab96baca6a9b43ba1d/src/doc/rustc/src/platform-support/thumbv7m_none_eabi.md

13:06 <adamgreig[m]> but it didn't get merged because the branch it was PR'd against got closed instead, and later someone else wrote a different thumb platform file here https://doc.rust-lang.org/nightly/rustc/platform-support/arm-none-eabi.html which doesn't talk about it at all

13:07 <adamgreig[m]> should it actually say +fp-armv8d16?

13:37 <M9names[m]> I would think so? The baseline makes sense (runs on both m4 and m7, useful for an mcu with both) but adding +fp64 means it can't run on m4, but also can't use everything that's available for m7.

13:37 <M9names[m]> https://developer.arm.com/documentation/ddi0489/f/floating-point-unit/about-the-fpu doesn't provide a lot of detail about the difference from vfp4 -> vfp5, maybe it doesn't matter much?

16:30 <wyager[m]> <adamgreig[m]> "should it actually say +fp-..." <- This flag also seems to generate the desired instructions, although I still get the unknown feature warning

17:07 <thejpster[m]> I think Cortex-M7 has an VFP5, not an Armv8 FPU, so I wouldn't suggest fp-armv8d16 for a Cortex-M7

17:09 <thejpster[m]> GCC at least has different options for the Armv8 FPU and the v5 FPU: https://wiki.segger.com/GCC_floating-point_options

17:09 <thejpster[m]> We need to write this up, run a bunch of tests, and get the target readme updated.

17:40 <thejpster[m]> You can see a list of supported features with:rustc --target=thumbv7em-none-eabihf --print target-features

17:41 <thejpster[m]> It distinguishes between "features supported by rustc for this target", and "codegen features supported by LLVM for this target"

17:42 <thejpster[m]> fp64 and m7 are LLVM options, fp-armv8 is a rustc option. I have no idea why.

17:45 <thejpster[m]> By default, thumbv7em-none-eabihf enables  "features": "+vfp4,-d32,-fp64",

17:46 <thejpster[m]> (d32: Extend FP to 32 double registers, fp64: Floating point unit supports double precision)

19:17 <thejpster[m]> Ugh I fell down the rabbit hole

19:18 <thejpster[m]> A vfp4-sp-d16 FPU can hold 16 double precision numbers but can’t do arithmetic on any of them, as it can only do single precision arithmetic. Still useful for argument passing I suppose.

19:19 <thejpster[m]> And cortex-m7 cpu type is still broken in LLVM because it unconditionally enables vfp5-d16 (I.e. double precision FPU instructions), even on a soft float target.

19:19 <thejpster[m]> And cortex-m-rt won’t enable your FPU so you’ll just have a bunch of pain.

19:20 <thejpster[m]> I’m going to write all this up.

19:46 <thejpster[m]> good grief, when did [Cortex-M52](https://developer.arm.com/Processors/Cortex-M52) turn up?!

19:46 <ithinuel[m]> A few months back.

19:47 <thejpster[m]> the thumbv8m.main-none-eabi is absurdly overloaded - M33, M52, M55 and M85. Optional DSP, Integer Helium, Floating Point Helium, and FPU.

19:47 <ithinuel[m]> https://community.arm.com/arm-community-blogs/b/internet-of-things-blog/posts/introducing-cortex-m52

19:47 <M9names[m]> <thejpster[m]> "fp64 and m7 are LLVM options, fp..." <- Did you see line 174 of the LLVM code I linked, that maps "+fp-armv8d16" to FPUVersion::VFPV5? I believe that's what rustc is calling.

19:47 <thejpster[m]> that is ... confusing

19:48 <thejpster[m]> because the M7 is definitely an Armv7E-M architecture implementation

19:48 <thejpster[m]> maybe fp-armv8 and VFP5 are effectively the same

19:48 <thejpster[m]> there's certainly no vfp5 rustc flag

19:50 <thejpster[m]> https://github.com/llvm/llvm-project/blob/601e102bdb55e12a2f791e0d68fd6f81ffc21e21/llvm/include/llvm/TargetParser/ARMTargetParser.def#L336

19:50 <thejpster[m]> CPU=M33 turns on VFP5, CPU=M55 turns on FP_ARMV8_FULLFP16_D16

21:11 <thejpster[m]> Given some -C target-cpu=cortex-m55 option, is it possible to see which target-features are enabled by that?

21:23 <thejpster[m]> I tried #[cfg(target_feature="...")] but it doesn't work on arm

22:00 <thejpster[m]> Here's what I've come up with for Armv8-m.main:

22:00 <thejpster[m]> https://hackmd.io/@thejpster/H1iTNJSRT

22:02 <thejpster[m]> LLVM is pretty neat: if you give it this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PPrJGilGvnrRnZXThiHlxvVM>)

22:03 <thejpster[m]> load that co-processor, and add four f32s at a time!

22:09 <M9names[m]> Do you need that loop to be unrolled for that lowering to happen?

22:18 <thejpster[m]> you need opt-level 3, yeah

22:24 <thejpster[m]> There's two kinds of Helium (aka M-Profile Vector Extensions) - integer only, and integer+float capable. +mve and +mve.fp. Even the integer one can turn:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/urrkcbWhuttMXvPfPEpgrPll>)

22:25 <thejpster[m]> although that 512 byte offset on r0 looks mighty weird. I wonder if any of this stuff is actually correct.