[llvm] [llvm] Ensure that soft float targets don't emit `fma()` libcalls. (PR #106615)

[Alex Rønne Petersen via llvm-commits]

alexrp wrote:

> This doesn't feel like the right place for this, I would expect there to be some legality check that would fail.

For what it's worth, what happened for the affected targets was that the `fmuladd` intrinsic was transformed into an FMA node in the SDAG due to `isFMAFasterThanFMulAndFAdd()` saying it's worthwhile to do so, and then legalization turned that FMA node into an `fma()` libcall due to soft float being in effect. That all seems sane enough to me. It's just that the `fma()` libcall in particular is problematic because:

1. For soft float, it's strictly more work than just doing the individual `fmul` + `fadd` compiler-rt libcalls.
2. It takes an extra dependency on libc even in freestanding.
3. It can cause the libc `fma()` implementation to call itself recursively (we observed this when compiling musl with `zig cc`).

Handling this special case in `isFMAFasterThanFMulAndFAdd()` seemed like the most straightforward solution, but I'm definitely open to suggestions.

https://github.com/llvm/llvm-project/pull/106615