On Wed, May 21, 2025 at 12:30 AM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>
> On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > > Hi Mike,
> > > Irrespective of whether -Ofast is used or not, should’nt we generate 
> > > XSCMPUDP instruction for ‘isgreater()’ operation? This is because 
> > > XSCMPGTDP insn will generate a trap if either operand is an SNaN or a 
> > > QNaN. Whereas, XSCMPUDP insn will generate a trap only if either operand 
> > > is an SNaN. The issue with the failing glibc tests is that an “Invalid 
> > > operation” exception is being thrown due to qNaNs.
> >
> > But -Ofast says not to worry about Nans (signalling or otherwise).  But if
> > Segher desires, I remove the test for Ofast.
>
> That is not what -Ofast means at all.  It means "-O3, but also
> -ffast-math, and some other not recommendable things".  Its name is a
> total misnomer: it often is not faster than even -O2 (the baseline
> here), but it also is very non-standard-compliant and similar things.

-ffinite-math-only is a promise to the compiler that no NaNs (quiet or
signalling)
or Infs exist as inputs to or produced by any expression in the program.  Mostly
helpful with arithmetic simplifications done as-if-it-were-math-and-not-FP.
Without -fsignalling-nans sNaNs are assumed to not exist (that's the default
btw).

> "-Ofast-and-loose" might be a name that does make sense.  As the
> dictionary says:
>    "If you say that someone is playing fast and loose, you are
>     expressing disapproval of them for behaving in a deceitful, immoral,
>     or irresponsible way."
>
> And yeah, xscmpgtdp is plain wrong no matter what flags are used, unless
> we adopt a -fuck-up flag :-(

The interesting question of course is why the instruction exists in
the first place?
And I agree that we shouldn't use it irrespective of
-ffinite-math-only unless it
is for magic reasons very much faster than the alternative (in the absence of
actual NaN values involved).

Richard.

>
>
> Segher

Reply via email to