WIwillglynn·Nov 11, 2020
> The ARM architecture floating point units (VFP, NEON) support RunFast mode, which includes flush-to-zero and default NaN. The latter means that payload of NaN operands is not propagated, all result NaNs have the default payload, so in R, even NA * 1 is NaN. Luckily, RunFast mode can be disabled, and when it is, the NaN payload propagation is friendlier to R NAs than with Intel SSE (NaN + NA is NA). We have therefore updated R to disable RunFast mode on ARM on startup, which resolved all the issues observed.
Hmm. ELF object files for Arm can represent this with build attributes [1]:
Tag_ABI_FP_denormal, (=20), uleb128
0 The user built this code knowing that denormal numbers might be flushed to (+) zero
1 The user permitted this code to depend on IEEE 754 denormal numbers
2 The user permitted this code to de
Read the rest
pend on the sign of a flushed-to-zero number being
preserved in the sign of 0
Tag_ABI_FP_number_model, (=23), uleb128
0 The user intended that this code should not use floating point numbers
1 The user permitted this code to use IEEE 754 format normal numbers only
2 The user permitted numbers, infinities, and one quiet NaN (see [RTABI32_])
3 The user permitted this code to use all the IEEE 754-defined FP encodings
Seems like their code should be tagged Tag_ABI_FP_denormal = 1, Tag_ABI_FP_number_model = 3 if it were an ELF .o, .so, or executable, in which case <waves hands> some other part of the toolchain or system would automatically configure the floating point unit to provide the required behavior.
Does Mach-O have a similar mechanism?
[1] https://github.com/ARM-software/abi-aa/blob/master/addenda32...