Default behavior of -fno-trapping-math for targets lacking trapping floating-point support

The LLVM option -fno-trapping-math disables code‑generation transformations that could raise floating‑point hardware traps, helping to produce reproducible builds.

While the flag is documented and respected in recent releases, there is an open discussion about enabling it by default for architectures that lack trapping floating‑point support, aiming to improve determinism without sacrificing performance.

The goal is to assess whether making -fno-trapping-math the default on such targets yields a net benefit, considering possible performance regressions and its undefined interaction with aggressive fast‑math options.

Should LLVM enable -fno-trapping-math by default for targets without trapping FP? What performance impact might be expected on typical workloads? How should the flag’s behavior be defined when combined with -ffast-math?