The SSE _mm_invsqrt_ps intrinsic is missing.

[gnzlbg]

Bugzilla Link	37343
Version	trunk
OS	All
CC	@topperc,@efriedma-quic,@RKSimon,@rotateright

Extended Description

The intel intrinsic guide https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_invsqrt_ps&expand=4513,3028,3028

Shows the intrinsic as:

__m128 _mm_invsqrt_ps (__m128 a)
#include <immintrin.h>
CPUID Flags: SSE
Description
Compute the inverse square root of packed single-precision (32-bit) floating-point elements in a, and store the results in dst.
Operation
FOR j := 0 to 3
i := j*32
dst[i+31:i] := InvSQRT(a[i+31:i])
ENDFOR
dst[MAX:128] := 0

But it is not implemented in the clang headers.

[gnzlbg]

ICC implements the intrinsic: https://godbolt.org/g/Etd5tL

[topperc]

This is an SVML function which requires a libary that comes with the Intel compiler.

[gnzlbg]

Isn't it possible to reimplement that in the clang headers? There are many composite instructions in the headers that clang already reimplements, how is this one different?

[efriedma-quic]

Is it suppposed to be the IEEE754 correctly rounded rSqrt, or some approximation?

[gnzlbg]

Is it suppposed to be the IEEE754 correctly rounded rSqrt, or some approximation?

The IEEE754 correctly rounded rSqrt.

The intrinsics for the approximation are already implemented in clang (_mm_rsqrt_ps and friends).

[efriedma-quic]

There are many possibilities in between rsqrtss and correctly rounded... for example, you could use rsqrtss plus one Newton-Raphson iteration, or 1/sqrt(x). I wouldn't assume the routine is correctly rounded unless there's documentation that says so or you've exahustively tested it.

[gnzlbg]

The documentation of the Intel SVML says that the accuracy is configurable: 11, 21, 24 mantissa bits precision for vectors of float, and 26, 50 and 53 for vectors of doubles. IIUC 24 bit precision and 53 bit precision is "full-precision".

[gnzlbg]

This is the relevant page: https://software.intel.com/en-us/ipp-dev-reference-invsqrt

AFAICT the precision is toggled globally for each function (e.g. invsqrt) using a compiler flag, see here: https://software.intel.com/en-us/cpp-compiler-18.0-developer-guide-and-reference-fimf-accuracy-bits-qimf-accuracy-bits

[efriedma-quic]

"maximum guaranteed error within 1 ulp" is not correctly rounded. Correctly rounded is within .5 ulp.

[topperc]

I think _mm_invsqrt_ps is rsqrtps and a newton-raphson step in the normal case. There's some additional handling for negative numbers and infinity I think. This is based on staring at the disassembly from a binary compiled with icc. I might try to see if I can get more info from others in the compiler group.

[rotateright]

Re: the accuracy of the estimate.

IIRC, when I was looking at that using the test programs attached to bug 21385, I could not get the estimates to converge to less than 1 ULP on a CPU without FMA...no matter how many NR steps were used.

Not sure if that's mathematically provable or if I just used the wrong ops in the refinement.

The output there suggests that it's not possible to get even to 1 ULP rounding with just 1 step.

[gnzlbg]

FWIW, our problem is that we can't really use these intrinsics on ICC because they are not available on Clang and GCC and the workarounds for them are impractical for us.

It would be enough if Clang would support these in such a way that they produce the same results as ICC, irrespectively of performance.

[topperc]

I mispoke yesterday in Comment 10. The icc code does a rsqrtps and a single newton raphson step for normal inputs. For negative inputs, 0.0, NANs, denormals, and infinity it falls back to a scalar loop with a lot of code. So its probably more complicated than just a naive sqrtps+divps.

Not knowing what that fall back path actually does, I don't know if we can match icc. And I certainly don't think we could inline it in a header file.

Gonzalo BG, I don't have a clear picture of what your requirements are.

Do you just care about the normal inputs? If yes why can't you just use the rsqrt intrinsic, and implement the newton raphson step yourself?

[gnzlbg]

@​Craig Topper,

I only care about getting the same outputs than ICC here. Having good performance would be nice, but is not a priority.

What I don't want is for binaries compiled with ICC that use this intrinsic to produce different results when compiled with Clang.