MDEV-34969: test fail main.spatial_utility_function_simplify #3553
Conversation
On aarch64 and when computing the perpendicular distance, we need to avoid the fmsub (Fused Multiply-Subtract) because it can return slightly different precision results when evaluating expressions like x = a - (b * c) such as we did (before this patch) in perpendicular-distance. Instead, we now store the result of the multiplication (b * c) and then subtract it from a which avoids (in all build types) fmsub. This error occurs because the C standard allows implementations to use higher precision throughout calculations before storing to the destination type. This can allow for differences in the final result if using higher precision meaningfully changes intermediate values which is what happened in our case. By breaking the operation into two, we prevent the use case where fmsub applies, even for optimized builds under our current build flags configuration. See also dotnet/runtime#64591 https://stackoverflow.com/questions/51124436/strange-issue-with-floating-point-accuracy-on-arm64
|
|
|
Ah, like #482. Good POC fix. I don't think it will take compilers long to started fusing a split bit of code. Is |
Thank you 😄 I wasn't aware of |
|
@grooverdan Googling a bit doesn't seem to turn up much useful. Maybe I'm holding it wrong. I looked at #482 and didn't see a use of it in that commit. Additionally, |
On
aarch64and when computing the perpendicular distance, we need to avoid thefmsub(Fused Multiply-Subtract) because it can return slightly different precision results when evaluating expressions likesuch as we did (before this patch) in perpendicular-distance. Instead, we now store the result of the multiplication
(b * c)and then subtract it fromawhich avoids (in all build types)fmsub.This error occurs because the C standard allows implementations to use higher precision throughout calculations before storing to the destination type. This can allow for differences in the final result if using higher precision meaningfully changes intermediate values which is what happened in our case. By breaking the operation into two, we prevent the use case where
fmsubapplies, even for optimized builds under our current build flags configuration. The compiler then decomposes the operation into separatefsubandfmulinstructions which corrects the result.See also
dotnet/runtime#64591
https://stackoverflow.com/questions/51124436/strange-issue-with-floating-point-accuracy-on-arm64