The current langref for @mulAdd says:
Fused multiply-add, similar to `(a * b) + c`, except only rounds once, and is thus more accurate.
However, @mulAdd doesn't guarantee that the operations are fused, it gives the compiler the option to fuse them. For example, the LLVM backend emits llvm.fmuladd for @mulAdd which only fuses the operations when FMA is supported and more efficient.
IMO the currently implemented behavior is desirable. For example, I'd like my rendering and physics code that uses @mulAdd to compile for all targets, but get a performance boost if FMA is supported. I wouldn't, for example, want it to try to emulate mulAdd or fail to compile when unsupported.
This PR updates the langref to match the current behavior.
The current langref for `@mulAdd` says:
```
Fused multiply-add, similar to `(a * b) + c`, except only rounds once, and is thus more accurate.
```
However, `@mulAdd` doesn't guarantee that the operations are fused, it gives the compiler the option to fuse them. For example, the LLVM backend emits `llvm.fmuladd` for `@mulAdd` which [only fuses the operations when FMA is supported and more efficient](https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic).
IMO the currently implemented behavior is desirable. For example, I'd like my rendering and physics code that uses `@mulAdd` to compile for all targets, but get a performance boost if FMA is supported. I wouldn't, for example, want it to try to emulate `mulAdd` or fail to compile when unsupported.
This PR updates the langref to match the current behavior.