How should Math.fma behave on platforms without hardware support? Which type of fallback?

[MaxGraey]

For example, LLVM provides two related intrinsics. The first one is llvm.fma which guarantees a fused multiply-add operation with a single rounding step, but it may be significantly slower on targets without a hardware FMA instruction. The second one is llvm.fmuladd which is relaxed version, which allows llvm to choose the most efficient lowering. It may be lowered either to a hardware FMA or to a regular a * b + c sequence with separate multiply and add operations, so it does not guarantee single-rounding semantics.

	llvm.fma	llvm.fmuladd
Strictness	Mandatory.	Optional / Permission to fuse.
Fallback	Lowers to a slow software call, e.g. libm's fmaf.	Decays back into separate fmul and fadd instructions.
Rounding Steps	Exactly one rounding step.	One if fused, two if split into separate operations.
Precision	Higher/consistent across hardware.	Platform-dependent floating-point behavior.

For example Julia lang has two versions:

• fma: https://www.jlhub.com/julia/manual/en/function/fma
• muladd: https://www.jlhub.com/julia/manual/en/function/muladd

So, you need to decide what the semantics of the fallback are? What is more important rounding precision or performance? Or both? If its's both (perf & rounding) than spec should define two fused mul+add operations like Julia & LLVM does

[bakkot]

I would not want this to be permitted to give different results on different platforms.

[MaxGraey]

I would not want this to be permitted to give different results on different platforms.

In this case make sense to add some constants like FP_FAST_FMAin C/++ so users will decide is it worth to use Math.fma in hot paths or not. Perf of software FMA usually slower of hardware's FMA in 10x-100x depending on the software implementation and platform

[ljharb]

That sounds like it would be a fingerprinting vector.

[MaxGraey]

That sounds like it would be a fingerprinting vector.

I would not want this to be permitted to give different results on different platforms.

Math.pow with a small const exponent is much more significant fingerprint vector expecially for v8/node.

The sin/cos implementations in libm, which are used by js engines under the hood also frequently use fma as well as other target-dependent conditional compilation. Therefore, nothing new is being introduced here.

Besides, most modern CPUs support hardware fma instruction. The exceptions are probably quite old intel/amd CPUs (everything before Haswell and Bulldozer, so more than 12 years old) and embedded systems but those may not even have an hardware FPU.

[MaxGraey]

I would not want this to be permitted to give different results on different platforms.

the difference between fma(a, b, c) and a * b + c (as software fallback) is just <= 0.5 ULP. That's nothing. No one JS engine can guarantee that kind of tolerance for any Math functions. Btw tests for libm libraries often just use an upper error ULP bound rather than an exact check, if it's not only extreme results like 0.0, NaN, +/-inf and etc. I know this very well, since I’ve implemented and tested more than one such library myself.

So math builtin function accuracy often varies from one JS engine to another, and even between different versions, from +1 to -1 ULP or more. And as I already said above, the spec does not regulate loower/upper precision bounds at all.

[bakkot]

Most Math namespace functions predate modern hardware and algorithms and the modern ecosystem where even tiny differences between engines can cause no end of headaches (as indeed the imprecision in Math.sin and friends has). This is not an excuse to carry this sloppiness into the future, especially for specialized operations like this one. Math.sumPrecise and Math.f16round are the only new functions added in the last decade and both require precise results.

[MaxGraey]

IEEE 754 precisely defines basic fp ops but real-world fp code still trades accuracy, performance and reproducibility. Bitwise-identical results across platforms are not guaranteed by default, especially with subnormals, FTZ/DAZ modes (ARM and TPU specifics), SIMD math approximate rsqrt, fma contraction, compiler flags, platform-dependent libm implementations. Language specs like C++ or Python generally do not require strict ULP bounds for every math function, so the practical goal is to minimize and document the ULP error.

[bakkot]

I'm aware; nevertheless I stand by my comments.