Numerical error introduced using ARM64 using clang-14 but not clang-13

[phargogh]

Hello! I am experiencing an issue with clang on ARM64 (reproducible on M1 mac and Raspberry Pi 4B) where chaining a series of mathematical operations together introduces some numerical error. I have a workaround where breaking some of the math onto a second line does not introduce the error. I have tested this on a Raspberry Pi 4B and also on the following debian versions on my M1 mac:

• debian buster (arm64, gcc 8.3.0, clang 7.0.1, no numerical issue)
• debian bullseye (arm64, gcc 10.2.1, clang 11.0.1-2, no numerical issue)
• debian bookworm (arm64, gcc 12.2.0, clang 13.0.1, no numerical issue)
• debian bookworm (arm64, gcc 12.2.0, clang 14.0.6, numerical issue present)
• debian trixie (arm64, gcc 13.2.0, clang 16.0.6, numerical issue present)
• debian sid (arm64, gcc 13.2.0, clang 16.0.6, numerical issue present)

A minimal reproducible sample is here in this gist: https://gist.github.com/phargogh/c4264b37e7f0beed31661eacce53d14a

Thank you!

[topperc]

Try passing -ffp-contract=off. The default was changed to -ffp-contract=on in clang 14.

-ffp-contract=on enables the use of FMA instructions for A * B + C if they appear in the same expression. FMA keeps the full precision of the multiply result before doing the addition. Using -ffp-contract=off causes the multiply result to be rounded to a double before doing the addition.

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: James Douglass (phargogh)

Hello! I am experiencing an issue with clang on ARM64 (reproducible on M1 mac and Raspberry Pi 4B) where chaining a series of mathematical operations together introduces some numerical error. I have a workaround where breaking some of the math onto a second line does not introduce the error. I have tested this on a Raspberry Pi 4B and also on the following debian versions on my M1 mac:

• debian buster (arm64, gcc 8.3.0, clang 7.0.1, no numerical issue)
• debian bullseye (arm64, gcc 10.2.1, clang 11.0.1-2, no numerical issue)
• debian bookworm (arm64, gcc 12.2.0, clang 13.0.1, no numerical issue)
• debian bookworm (arm64, gcc 12.2.0, clang 14.0.6, numerical issue present)
• debian trixie (arm64, gcc 13.2.0, clang 16.0.6, numerical issue present)
• debian sid (arm64, gcc 13.2.0, clang 16.0.6, numerical issue present)

A minimal reproducible sample is here in this gist: https://gist.github.com/phargogh/c4264b37e7f0beed31661eacce53d14a

Thank you!

[phargogh]

Thanks @topperc ! I confirm that the behavior is "restored" with -ffp-contract=off. I'll make sure our builds reflect this extra flag.

Although, I'm a little perplexed about why this behavior is creating different results on ARM64 vs X86_64. Any ideas?

[arsenm]

Thanks @topperc ! I confirm that the behavior is "restored" with -ffp-contract=off. I'll make sure our builds reflect this extra flag.

Although, I'm a little perplexed about why this behavior is creating different results on ARM64 vs X86_64. Any ideas?

Because the decision is based on whether the backend thinks FMA is fast. That will always be yes on arm64, and for base x86_64 it will be no. If you use -mfma or target any modernish CPU you'll probably get the fused result

[phargogh]

Thanks for the information! I think my issue is resolved here, so I'll go ahead and close the issue.