https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #17) > (In reply to rguent...@suse.de from comment #15) > > I think flushing denormals makes sense for "forward" propagation, > > Well, it still hurts quite a lot exactly for the ranges around zero. > Given that most CPU honor it most of the time, I think asking users > to use -funsafe-math-optimizations/-ffast-math/-Ofast if they instruct > the CPU not to do that is fine (different situation is Alpha where it > is the default behavior). Hmm, I guess if users enable FTZ we could instruct them to tell that to the compiler, but requiring -funsafe-math-optimizations is quite a difficult suggestion here. Maybe we can add a special -fftz flag for this (or do it per target, -mftz)? Maybe name it in a way not suggesting the compiler should FTZ but the compiler should assume the CPU would (-mprocess-ftz?). Maybe -fassume-fp-ftz? I suppose a user altering MSRS to enable FTZ leave any standards grounds ... > > Given -ffast-math on x86 enables FTZ we'd have to be conservative there > > as well. But OTOH we don't have any HONOR_DENORMALS or so? > > We don't but that is roughly what my patch adds... > > > Note the testcase in this PR was about -Ofast ... > > Indeed, for ranges from comparisons we could ignore the > flush_denormals_to_zero calls always; guess we'd need to add some defaulted > new flag to set, pass true to it from > the comparisons and don't call it if the flag is set. > In addition or instead of the above patch. Aldy? I guess _just_ doing this for compares at this point feels safer to me.
