Anyone knows why sqrt() call checks this?

In this simple code, for x86-64:

Code:

---

double f( double x ) { return sqrt( x ); }

---

The compiler creates code like this:

Code:

---

f:
  pxor    xmm2, xmm2
  sqrtsd  xmm1, xmm0
  ucomisd xmm2, xmm0
  ja  .L8            ; 0 > x?
  movapd  xmm0, xmm1
  ret
.L8:
  sub    rsp, 24

  ; store SQRTSD result on stack.
  movsd  QWORD [rsp+8], xmm1

  call    sqrt  ; why? sqrt() doesn't use the stack!

  ; Get result back from stack (zeroing upper bits).
  movsd  xmm1, QWORD [rsp+8]

  add    rsp, 24

  ; Use SQRTSD result anyway!
  movapd  xmm0, xmm1
  ret

---

Testing the direct use of SQRTSD against this routine with invalid values (x < 0.0, x = -0.0, +/-NAN or +/-INFINITE) I see no difference. And why calls sqrt() if it will recover XMM1 from stack?

The compiler does something similar if using fp87 instructions.

Strange...

The same thing happens for other processors... What am I missing?

Cortex-A53 AArch64 code:

Code:

---

f:
  fsqrt d1, d0
  fcmp  d0, #0.0
  bmi .L8
  fmov  d0, d1
  ret
.L8:
  stp x29, x30, [sp, -32]!
  add x29, sp, 0
  str d1, [x29, 24]
  bl  sqrt
  ldr d1, [x29, 24]
  ldp x29, x30, [sp], 32
  fmov  d0, d1
  ret

---

Have you considered posting that question on a non-C specific board?

You may get better answers :)

It's up to the compiler's discretion how the parameters are passed to functions. Unless mandatory by some specification (such as stdcall), the parameters don't have to be pushed on the stack.

Quote:

---

Originally Posted by GReaper

It's up to the compiler's discretion how the parameters are passed to functions. Unless mandatory by some specification (such as stdcall), the parameters don't have to be pushed on the stack.

---

That's not the question and I forgot to say under SysV ABI x86-64 (and AArch64) calling convention.

The question is: Why the C compiler is testing for x < 0, calling the sqrt() library function and using the result of a previous instruction anyways?

My test code:

Code:

---

#ifndef __GNUC__
#error Compiles only on GCC.
#endif

#if !defined(__386__) && !defined(__x86_64__)
#error Compiles only for Intel/AMD processors.
#endif

#include <stdio.h>
#include <x86intrin.h>
#include <math.h>

__attribute__((noinline))
static float sqrtf_sse( float );

__attribute__((noinline))
static float sqrtf_lm( float );

int main( void )
{
  static float invalid[] = { -0.0f, -1.0f, NAN, -NAN, INFINITY, -INFINITY };
  float f;
  int i;

  for (i = 0; i < sizeof invalid / sizeof invalid[0]; i++)
  {
    f = invalid[i];

    printf( "libm sqrtf(%1$f) = %2$f,\n"
            "sse  sqrtf(%1$f) = %3$f\n\n",
      invalid[i],
      sqrtf_lm( f ),
      sqrtf_sse( f ) );
  } 
}

// This will be a strange multiple instructions (+RET) not inline code.
float sqrtf_lm( float x )
{
  return sqrtf( x );
}

// This will be a single instruction (+RET) not inline code.
float sqrtf_sse( float x )
{
  __m128 r;

  __asm__ __volatile__ (
    "sqrtss %0,%1"
    : "=x" (r) : "xm" (x)
  );

  return _mm_cvtss_f32( r );
}

---

sqrt_libm() is a code like I showed before. The results (I didn't test for sNaN):

Quote:

---

libm sqrtf(-0.000000) = -0.000000,
sse sqrtf(-0.000000) = -0.000000

libm sqrtf(-1.000000) = -nan,
sse sqrtf(-1.000000) = -nan

libm sqrtf(nan) = nan,
sse sqrtf(nan) = nan

libm sqrtf(-nan) = -nan,
sse sqrtf(-nan) = -nan

libm sqrtf(inf) = inf,
sse sqrtf(inf) = inf

libm sqrtf(-inf) = -nan,
sse sqrtf(-inf) = -nan

---

Have you considered sending an email to the developers for your compiler?

FYI: This is a BUG of GCC until version 7.3 (Ubuntu/Debian), for i386 and amd64 and ARM AArch64, and version 6.3 for ARM AArch32. MinGW-w64 GCC version 7.3 generates the correct code.

This bug is inoffensive, since it just ignores the result of libm's sqrtf() -- or sqrt() for doubles -- and uses sqrtss (or sqrtsd or fp87 equivalents if -mfpmath=387) results anyway.

I don't know if it was fixed on gcc 8.

PS: Visual Studio (CL.EXE, from VC 14 on VSC 2019) create a simple call to sqrtf(), which is inside MSVCRT??.DLL, and it is slower. NO source code is available (what a surprise!).

Follow up from GCC bugzilla... sqrtf(), from libm, is called just to set errno.
Technically, not a bug, but inefficient code (my comment)...

And you can avoid using assembly inline using -ffast-math option (enabled by default only on -Ofast optimization).