[Bug middle-end/94083] inefficient soft-float x!=Inf code

[harald at gigawatt dot nl via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

--- Comment #7 from Harald van Dijk  ---
(In reply to Joseph S. Myers from comment #6)
> Contrary to what was claimed in bug 66462, I don't think there ever was a
> fixed patch. Note that in bug 66462 comment 19, "June" is June 2017 but
> "November" is November 2016 - the "November" one is the *older* one.

Ah, sorry, I misunderstood the situation. According to
 the earlier
version of that patch (the November 2016 one) was the one that did not have the
problems that caused it to be reverted. In response to review of that, big
changes were requested and in the process bugs were introduced. The buggy
version was then committed and reverted. The original version that did not have
those bugs could still be committed if a re-review, taking into account the
bugs that the rework introduced, would now see it as acceptable.

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[jsm28 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

--- Comment #6 from Joseph S. Myers  ---
Contrary to what was claimed in bug 66462, I don't think there ever was a fixed
patch. Note that in bug 66462 comment 19, "June" is June 2017 but "November" is
November 2016 - the "November" one is the *older* one.

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

--- Comment #5 from Jakub Jelinek  ---
Ah, ok.  So then expansion should just concentrate on the fabs (x) <= nextafter
(inf, 0) case for soft-float case and defer the rest to PR66462 which would
handle that much earlier.

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[harald at gigawatt dot nl via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #4 from Harald van Dijk  ---
(In reply to Jakub Jelinek from comment #3)
> Shall __builtin_isinf (x) or __builtin_isinf_sign (x) raise exception if x
> is a sNaN?
> Or never? Or it can but doesn't have to?

Never.

See also bug #66462 which also has a not-quite-right patch that was committed
and reverted, and the fixed patch posted but never committed and then
forgotten. I'm not 100% sure of the impact of that patch on soft-float but at a
quick glance it seems to use bitwise integer arithmetic which should avoid
libcalls entirely.

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Shall __builtin_isinf (x) or __builtin_isinf_sign (x) raise exception if x is a
sNaN?
Or never? Or it can but doesn't have to?
glibc's
int64_t hx,lx;
GET_LDOUBLE_WORDS64(hx,lx,x);
lx |= (hx & 0x7fffLL) ^ 0x7fffLL;
lx |= -lx;
return ~(lx >> 63) & (hx >> 62);
doesn't, but I think when we lower __builtin_isinf to fabs (x) (which should
just clear the sign bit, not raise exception) u<= ,
it would.
If we wouldn't need to raise exception, I think fastest would be to pattern
recognize the fabs (x) <=  and emit there the (lx | ((hx &
0x7fffLL) ^ 0x7fffLL)) != 0.
But __builtin_islessequal (__builtin_fabsf128 (x), __builtin_nextafterf128
(__builtin_inff128 (), 0.0f128)) I think should raise exception and those 2
will be indistinguishable, so maybe just recognize that case during expansion
if 2 libcalls would be needed and emit the equality comparison instead.
Or do both depending on if -fsignaling-nans is specified or not?

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed. Also happens with _Float128 on x86_64 since that is a soft-float fp
type too.

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

Andrew Pinski  changed:

   What|Removed |Added

 CC||g.peterh...@t-online.de

--- Comment #1 from Andrew Pinski  ---
*** Bug 114131 has been marked as a duplicate of this bug. ***

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|minor   |enhancement

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[wilson at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

The original bug report was apparently lost in the sourceware/gcc migration
back in the spring and I didn't notice until now.

This testcase

int foo(void) {
  volatile float f, g;
  intn;
  f = __builtin_huge_valf();
  g = __builtin_huge_valf();
  n += 1 - (f != __builtin_huge_valf());
  return n;
}

compiled for soft-float with -O2, and looking at the original tree dump I see

  f =  Inf;
  g =  Inf;
  SAVE_EXPR ;, n =
SAVE_EX
PR  + n;;

So the C front end converted the f != Inf compare to a f u<=
 compare, but the problem here is that the !=
operation is a single libcall, but u<= is two libcalls.  So code that should
have a single soft-float libcall ends up with two.  First a call to __unordsf2,
then a compare and branch, and then a call to __lesf2.  This is a
de-optimization.

Perhaps we can convert the f u<=  back to f != Inf in
the optimization to get a single libcall.  Or maybe we can add unordered
soft-float libcalls like ulesf2.

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |minor

--- Comment #1 from Andrew Pinski  ---
Most people don't use soft-float these days except for the low-end embedded
folks.  And even then, the low-end embedded folks try to avoid floating point.

So I don't know many people who cares about soft-float.