Implement -ffast-math flag mapping to wasm-opt --fast-math

[devalgupta404]

Implement -ffast-math flag mapping to wasm-opt --fast-math

Description

This PR implements the mapping from the -ffast-math compiler flag to the wasm-opt --fast-math optimization flag, as requested in issue #21497.

Changes Made

1. Added FAST_MATH Setting (src/settings.js)

• Added FAST_MATH setting in the Tuning section with default value 0
• Added comprehensive documentation explaining the setting
• Marked as [link] flag as it affects wasm-opt during linking

2. Command Line Flag Handling (tools/cmdline.py)

• Added handling for -ffast-math flag to set FAST_MATH = 1
• Enhanced -Ofast optimization level to also enable fast math (since -Ofast typically includes -ffast-math semantics)
• Removed the TODO comment as the feature is now implemented

3. wasm-opt Integration (tools/building.py)

• Modified get_last_binaryen_opts() function to include --fast-math flag when FAST_MATH setting is enabled
• Maintains backward compatibility - no --fast-math flag when FAST_MATH = 0

How It Works

• Without -ffast-math: Normal behavior, no --fast-math flag passed to wasm-opt
• With -ffast-math: Sets FAST_MATH = 1, causing wasm-opt to receive --fast-math flag
• With -Ofast: Automatically enables fast math optimizations (standard behavior)

[sbc100]

Can we test this somehow?

[devalgupta404]

Fast Math Flag Validation

Unit Tests

Focused unit test test/unit/test_fast_math.py verifies the same behavior at the last decision point that assembles wasm-opt args:

• With FAST_MATH=0, assert --fast-math NOT in opts
• With FAST_MATH=1, assert --fast-math IN opts
• 

---

Direct Invocation

This shows the final Binaryen flags returned by tools.building.get_last_binaryen_opts() when toggling the internal setting:

• When FAST_MATH=0 → --fast-math is excluded
• When FAST_MATH=1 → --fast-math is included

FAST_MATH	Expected Flag Behavior	Test Result
0	--fast-math not present	✅ Pass
1	--fast-math present	✅ Pass

[devalgupta404]

if you want i can push the tests also

[sbc100]

We normally like to do black box test of emcc, so maybe here we could have a test that using emcc -v (prints subcommands to stderr).. you could then find the wasm-opt sub-command in the stdout and confirm that it contains (or does not contains) the fast math flag.

[dschuff]

This PR implements the mapping from the -ffast-math compiler flag to the wasm-opt --fast-math optimization flag, as requested in issue #21497.

Did anyone actually request this? Can you say more about your use case?

[devalgupta404]

Many applications use floating point math extensively so -ffast-math flag enables aggressive optimizations that can significantly improve performance around 10-30% improvement without code changes and the issue #21497 requesting this feature specifically.

[devalgupta404]

sir i just sync my fork so there are lot of changes please either consider the commits or if you want i will close this PR and open new PR.

[kripken]

Hmm, such changes shouldn't appear when merging in latest upstream. How did you merge? Perhaps something went wrong there.

[dschuff]

Many applications use floating point math extensively so -ffast-math flag enables aggressive optimizations that can significantly improve performance around 10-30% improvement without code changes and the issue #21497 requesting this feature specifically.

My point is that issue #21497 actually does not request this feature specifically. It's entirely speculative. That's why I'm curious about the use case here. 10-30% sounds pretty good! Is that specifically for Binaryen fast math or for fast-math overall? what kind of application is this?

[devalgupta404]

@kripken i raised a new pr can you please look that so that it is easy to merge https://github.com/emscripten-core/emscripten/pull/25513

[devalgupta404]

@dschuff there is TODO present in tools/cmdline.py (line 297-299). It is clearly mentioned to use this method