andykaylor wrote: > Just to be clear: I'm not proposing entirely eliminating the "link against > crtfastmath.o" behavior, when linking a binary with `-ffast-math` (though, > separately from _this_ review, that may be worth considering!). I only meant > we should stop attempting to infer anything about `-fdenormal-fp-math` due to > using `-ffast-math`. (as per the other paragraph in my last comment).
Are youe suggesting that we should continue linking against crtfastmath.o when it is available and fast-math is enabled but we should set the "denormal-fp-math" attributes to "ieee" or "dynamic"? I want to make sure I'm understanding you correctly. Personally, I don't like linking with crtfastmath.o to get this behavior. I would prefer to insert code into whatever function(s), if any, we identify as a relevant entry point. That would require having the attribute set, at least for the entry function(s). Linking with crtfastmath.o depends on finding it, which I think makes it dependent on the GNU toolchain, and the static initializer is less visible to users debugging their program. 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, but if it's useful for other targets, we shouldn't take that away. https://github.com/llvm/llvm-project/pull/80475 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
