andykaylor wrote: > This effort is highly desirable, c.f. this [blog > post](https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html), > so thanks for that! > > Xref: #57589, #80475, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
My patch here still leaves the problem that we're conflating the "denormal-fp-math" attribute with the desire to set FTZ/DAZ on startup. I think @jcranmer-intel's patch is more important because it actually does something about the shared library problem. Honestly, my goal here is quite different than what he's doing there. I want to make sure that we are setting FTZ+DAZ during startup when the application entry point is compiled with fast-math enabled. I'd like to eliminate the dependence on crtfastmath.o and set the flags in the FP control register directly in main() when that's what we intended. I'm not sure what the correct behavior is across all platforms. My perspective on this is heavily X86-biased, so I'd really like some guidance from people who work on other targets about their expectations. I think I saw at least one target that sets denormal-fp-math=preservesign as their default even without any fast-math options enabled. It wouldn't surprise me if there are targets that don't want to set denormal-fp-math=preservesign even with fast-math. For some(?) Linux targets, we've got the mess I'm touching here where the driver is looking for crtfastmath.o and trying to inspect the command-line for fast-math settings outside the other FP option rendering, and then the FP option rendering, which is meant to be target-independent, is kind of making a mess of it, especially with inconsistent handling of "denormal-fp-math" and "denormal-fp32-math". https://github.com/llvm/llvm-project/pull/89477 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
