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.

Reply via email to