[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)

[James Y Knight via cfe-commits]

jyknight wrote:

I'm proposing a simple change we can make _now_, in order to unblock this PR which at least gets rid of crtfastmath for shared libraries! I don't think this needs to be the end of the story; additional, more large-scale changes can be made afterwards...

> Are youe suggesting that we should continue linking against crtfastmath.o when it is available and fast-math is enabled

I'm suggesting no additional changes regarding when to link crtfastmath vs what's present in this PR.

> but we should set the "denormal-fp-math" attributes to "ieee" or "dynamic"? I want to make sure I'm understanding you correctly.

I'm suggesting that we modify Clang so that `-ffast-math` _doesn't affect_ `denormal-fp-math`, by (as I mentioned before) removing the overload [Linux::getDefaultDenormalModeForType](https://github.com/llvm/llvm-project/blob/d4c5acac99e83ffa12d2d720c9e502a181cbd7ea/clang/lib/Driver/ToolChains/Linux.cpp#L838). This makes Clang for Linux X86 and X86-64 work the same as every other OS/CPU combo.

Yes, this means we have the wrong mode, sometimes. But: that is not a _new_ problem -- we use the wrong mode all the time already. And ISTM the issues that arise are within the expected bounds of `-ffast-math` wrongness.

> For x86-based CPU targets, we really shouldn't be making assumptions about the FTZ/DAZ state for any function where we aren't setting it

If you'd make another PR proposing to expose `-fdenormal-fp-math=dynamic` to the Clang command-line, and making that the _default_ for most targets, that seems potentially interesting to discuss. I don't really know the impact, and I also don't think it needs to be concluded before making the changes for this PR.

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