Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix non-determinism in global placement caused by different FFT output values #4518

Merged
merged 2 commits into from
Jan 10, 2024

Conversation

mithro
Copy link
Contributor

@mithro mithro commented Jan 10, 2024

The global placement depends on the output of the FFT library. Without -ffp-contract=off the current FFT library produces different results dependent on if the compiler is targeting an x86 architecture which has the "FMA instruction".

The FMA instruction omits the rounding done in the multiplication instruction, making the calculations produce different results for some input values

See https://kristerw.github.io/2021/11/09/fp-contract/

This pull request;

  • Adds a test for the FFT library which checks the floating point output is correct.
  • Turns -ffp-contract=off on for the whole of OpenROAD to make sure the floating point values are deterministic.

The `fft_test` checks that the FFT output is deterministic despite using
floating point values.

Signed-off-by: Tim 'mithro' Ansell <tansell@google.com>
GCC per default enables one optimization for x86_64 that can change the
result of floating-point operations: -ffp-contract=fast.

This allows the compiler to do floating-point expression contraction
such as combining multiplication and addition instructions with an FMA
instruction. However, the FMA instruction omits the rounding done in the
multiplication instruction, making the calculations produce different
results for some input values.

Disabling floating-point contraction with -ffp-contract=off makes GCC
generate code that produces a consistent result for x86_64.

See https://kristerw.github.io/2021/11/09/fp-contract/

The `fft_test` checks that this is working correctly.

Signed-off-by: Tim 'mithro' Ansell <tansell@google.com>
Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

Copy link
Collaborator

@QuantamHD QuantamHD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incredible Debugging!

mithro added a commit to mithro/bazel_rules_hdl that referenced this pull request Jan 10, 2024
This is needed for floating point stability.

The global placement depends on the output of the FFT library. Without
`-ffp-contract=off` the current FFT library produces different results
dependent on if the compiler is targeting an x86 architecture which has
the "FMA instruction".

The FMA instruction omits the rounding done in the multiplication
instruction, making the calculations produce different results for some
input values

See https://kristerw.github.io/2021/11/09/fp-contract/

See also OpenROAD change @
The-OpenROAD-Project/OpenROAD#4518

Signed-off-by: Tim 'mithro' Ansell <tansell@google.com>
@maliberty maliberty merged commit 793f5bf into The-OpenROAD-Project:master Jan 10, 2024
13 checks passed
mithro added a commit to mithro/bazel_rules_hdl that referenced this pull request Jan 10, 2024
This is needed for floating point stability.

The global placement depends on the output of the FFT library. Without
`-ffp-contract=off` the current FFT library produces different results
dependent on if the compiler is targeting an x86 architecture which has
the "FMA instruction".

The FMA instruction omits the rounding done in the multiplication
instruction, making the calculations produce different results for some
input values

See https://kristerw.github.io/2021/11/09/fp-contract/

See also OpenROAD change @
The-OpenROAD-Project/OpenROAD#4518

Signed-off-by: Tim Ansell <tansell@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants