Missing builtin: __builtin_ia32_sqrtsd

[bjacob]

GCC-compatible compilers support various builtins that give access to specific instructions not otherwise covered by standard intrinsics.

__builtin_ia32_sqrtsd is an example. It gives access to scalar (non-SIMD) square-root instruction SQRTSD.

It's used by Eigen, so lack of support currently means that Eigen has to special-case Emscripten.

Testcase:

include <xmmintrin.h>

int main() {
double x = 0;
__builtin_ia32_sqrtsd(_mm_set_sd(x));
}

Result:

/usr/local/google/home/benoitjacob/vrac/missing-builtin-sqrt.cc:5:3: error: use of undeclared identifier '__builtin_ia32_sqrtsd'
__builtin_ia32_sqrtsd(_mm_set_sd(x));

[bjacob]

Note: this testcase uses _mm_set_sd, which is also unsupported by Emscripten, see Issue #4089.

[juj]

To format such test cases correctly, try prepending them with four spaces. The __builtin_ia32 intrinsics are platform specific and not currently supported. For SQRTSD instruction specifically, try using the _mm_sqrt_sd() intrinsic instead, which does the same thing. Does Eigen have a build mode that would use the standard intrinsics?

[bjacob]

Thanks, I didn't know about _mm_sqrt_sd. Will fix Eigen to use it.

[bjacob]

Actually, Eigen was staying away from it to work around a GCC codegen performance bug, but we can handle this differently.

[juj]

We could get these to converge by adding reroutes like #define __builtin_ia32_sqrtsd _mm_set_sd into Emscripten's emmintrin.h. They wouldn't be real intrinsics, but that would be considerably less effort than setting up hundreds of new call handlers to Emscripten LLVM side.

[bjacob]

Up to you depending, I guess, on whether other applications out there also rely on this builtin. For now, I've fixed Eigen:
https://bitbucket.org/eigen/eigen/commits/03b73e169a3ea60cf9fa0e20b0a5032f4deaf2b6

[juj]

Looks good, recommend using the predefine __EMSCRIPTEN__ instead of EMSCRIPTEN though.

[bjacob]

ah, thanks!

2016-02-10 12:46 GMT-05:00 juj notifications@github.com:

Looks good, recommend using the predefine EMSCRIPTEN instead of
EMSCRIPTEN though.

—
Reply to this email directly or view it on GitHub
#4088 (comment)
.

[juj]

On other thought, it's probably best to leave these out, since examining https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/X86-Built-in-Functions.html, one uses the CPU-specific intrinsics over the portable ones when one wants to emit a specific hardware instruction. Supporting these in Emscripten would be a bit like false advertising since SIMD.js doesn't have support for that. If someone makes the choice of using a nonportable CPU-specific function, then it's to be expected that it will give a nonportable result, and it's better to explicitly not support the case, but to steer code paths to utilize the standard intrinsics instead.