0

I thought that I do not want to use SSE instructions in libc library functions like strcpy().

So I attempted to build from source code with option -mno-sse. However, I got an error like the following, I could not make it.

 ../stdlib/bits/stdlib-float.h: In function ‘atof’:
 ../stdlib/bits/stdlib-float.h:26:1: error: SSE register return with SSE disabled

Is there anyone who knows the cause? Is there anyone who can solve it ?

pinenight
  • 15
  • 5
  • why do you think you don't want to use SSE instructions? – Grady Player Nov 20 '18 at 05:49
  • @GradyPlayer The only thing I can think is that the OP is writing some sort of kernel code where SIMD register usage is banned or highly discouraged. – Mysticial Nov 20 '18 at 16:42
  • well the calling convention is different for syscalls anyway... maybe there is an attribute decorator... also you could make them variadic, and everything would be pushed onto the stack – Grady Player Nov 20 '18 at 20:58
  • @GradyPlayer This is what I am working on right now. https://stackoverflow.com/questions/53312772/intel-pininvalid-reg-for-iarg-reg-value-reg-xmm0 In the process of addressing this problem, I got a question and asked a question. – pinenight Nov 21 '18 at 06:00

1 Answers1

1

The x86-64 System V ABI's calling convention returns float and double in XMM registers.

SSE2 is baseline for x86-64. 64-bit code can assume it without checking, so the standard calling convention uses it. You never need to disable SSE2 for compatibility with hardware.

To compile without SSE for x86-64, you'll need a compiler that can use an alternate calling convention for floating point, or you'll need to build glibc without any floating point args or return values if that's even possible. (FP code within a function is fine; gcc knows how to fall back to x87 if SSE isn't available, even in 64-bit code.)

Even then, there might not be a hand-written x86-64 asm version of strcpy without SSE2 in glibc, only for 32-bit x86. So glibc may not compile for that reason even if you did avoid the float/double problem. And if it does, the generic C strcpy will suck for performance compared to SSE2.

It should work fine to build glibc for 32-bit x86 without SSE. The i386 System V ABI's calling convention passes FP args on the stack, and returns them in x87 st0.

SSE is an optional extension to 32-bit x86; not all 32-bit-only CPUs have it, so toolchains and libraries do need to support being compiled without it.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • Thank you for your comment. Is there no choice but to change the compiler to another, or change the source code of glibc ... – pinenight Nov 20 '18 at 05:49
  • @pinenight: I don't know if there's a way to get gcc to use an alternate non-SSE ABI for x86-64. Even if there was, you wouldn't be able to call any `float` or `double` functions from normal code, so many programs that wanted to use this custom libc would have to be recompiled, too. (`libm` is a separate file, but many programs that use FP at all use `printf` with FP formats and that's in `libc`.) – Peter Cordes Nov 20 '18 at 06:52
  • If you want to disable SSE/SSE2 only for some specific hand-written asm functions (like memcpy and strcpy), you could maintain binary compatibility, but you would probably need to tweak the source code to disable the normal dispatching to AVX / SSE versions when available. `strcpy` without SSE2 is not going to be efficient, but `memcpy` with `rep movsb` is not bad on CPUs with ERMSB. – Peter Cordes Nov 20 '18 at 06:57