[Bug target/103008] poor inlined builtin_fmod on x86_64

["ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
FYI, the following testcase:

--cut here--
#include <math.h>

float
__attribute__((noinline))
_fmodf (float x, float y)
{
  return x - truncf (x/y) * y;
}

int
main ()
{

  float a, b;
  volatile float z;

  for (a = -1000.0f; a < 1000.0f; a += 0.01f)
    for (b = -1000.0f; b < 1000.0f; b += 0.1f)
      z = fmodf (a, b);

  return 0;
}
--cut here--

$ gcc -Ofast -lm fmod-bench.c

      22,127092116 seconds time elapsed

      22,125111000 seconds user
       0,000999000 seconds sys


$ gcc -Ofast -fno-builtin-fmodf -lm fmod-bench.c

      32,751589079 seconds time elapsed

      32,746156000 seconds user
       0,000999000 seconds sys


Which points that the x87 code is considerably faster on my target
(Ivybridge-E) on Fedora-34 with glibc-2.33.

For reference, when the above _fmodf is called, I get:

$ gcc -Ofast -lm fmod-bench.c

      10,706189749 seconds time elapsed

      10,704859000 seconds user
       0,000999000 seconds sys

$ gcc -Ofast -lm -msse4 fmod-bench.c

      11,391062747 seconds time elapsed

      11,390771000 seconds user
       0,000000000 seconds sys

So, considerable faster!

It looks that with -ffast-math it is not inlined x87 code that is problematic,
but the missing fmod transformation. As shown above, the SSE2 code for truncf
is on par with SSE4 roundss instruction, so if the target can provide optimized
truncf code, the fmodf should definitely be converted to "a - trunc (a/p) * p".