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

[wilson at gcc dot gnu.org]

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;
  int            n;
  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 <!(f u<= 3.4028234663852885981170418348451692544e+38)>;, n =
SAVE_EX
PR <!(f u<= 3.4028234663852885981170418348451692544e+38)> + n;;

So the C front end converted the f != Inf compare to a f u<=
<max-representable-float> 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<= <max-representable-float> back to f != Inf in
the optimization to get a single libcall.  Or maybe we can add unordered
soft-float libcalls like ulesf2.