Describe limitations of floating point atomics

[smithp35]

The atomicsabi presents a baseline sequence of instructions and their equivalent atomic instruction. For floating point atomics the instruction sequences are not always equivalent, particularly when related to updating the floating point environment.

We should document the limitations of floating point atomics so that readers are aware of them.

The known issues:

• The loop variants corrupt the FP status flags. This can be mitigated by saving/restoring and using the results of the final iteration. C and C++ may disagree on whether this is needed.
• FEAT_LSFE changes the default control bits fpcr, which would require the control bits to be saved and restored.

[mmalcomson]

I'd like to double-check: The above says that FEAT_LSFE changes the default control bits fpcr.
I thought the relevant instructions behave as if the FPCR is different (rather than changing anything).
Is that just me reading too much into the way the sentence was written or a detail that I'd missed?

[smithp35]

I'd like to double-check: The above says that FEAT_LSFE changes the default control bits fpcr. I thought the relevant instructions behave as if the FPCR is different (rather than changing anything). Is that just me reading too much into the way the sentence was written or a detail that I'd missed?

I'll see what I can find out. I'm trying to record a discussion with @Wilco1 . The context was of N threads doing N floating point operations, could there be any guarantee of what the final result would be due to the order of operations.

I can't find anything in the pseudo code that suggests the FPCR is permanently changed. Closest I can find is https://developer.arm.com/documentation/ddi0487/maa/-Part-J-Architectural-Pseudocode/-Chapter-J1-A-profile-Architecture-Pseudocode/-J1-1-Pseudocode-for-AArch64-operation/-J1-1-306-MemAtomicFP?lang=en#asl_impl_aarch64_mematomicfp_3

but this suggests that a local copy fpcr is made of the system FPCR.

[Wilco1]

The "which would require the control bits to be saved and restored" applies to the loop variant if we wanted a loop that behaves like the LSFE instruction. So it's not just hard but also extremely inefficient to create equivalent sequences.

The N threads comment is about the general issue with floating point atomics. Floating point is inherently non-associative, so multiple threads adding N values can result in N different results depending on the order they execute in. Hence you get both random results and status flags in each thread even if you use the same atomic sequence.

So we could use the sequences as documented as long as we're clear about these differences and the general limitations of FP atomics.