fix clobbering RBX register in LTO mode within ZSTD_cpuid

[virt00l]

Just rewrite assembly to using std intrinsics for all compilers. It doing right thing by default (e.g. preserving aftermentioned register).

Bug actually was caught on certain Japan's console in LTO mode (PIC is also turned on) but I suspect that same would be true for other platforms as well (e e.g. Linux+PIC+LTO)

[terrelln]

Hey @virt00l, thanks for the report! We port our implementation from folly/CpuId.h. It looks like they had a similar issue with the __cpuid() intrinsic on Windows compiled with Clang.

I'd like to keep our implementation as close as possible to upstream. Could you try applying a C equivalent of this commit and see if it fixes your issue?

[virt00l]

Hey @virt00l, thanks for the report! We port our implementation from folly/CpuId.h. It looks like they had a similar issue with the __cpuid() intrinsic on Windows compiled with Clang.

I'd like to keep our implementation as close as possible to upstream. Could you try applying a C equivalent of this commit and see if it fixes your issue?

I don't have time to do it verbatim right now, but it seems that it's indeed very likely that it does.
Even older clang-11 based SDKs has this patch applied it seems:
https://reviews.llvm.org/rGe0c7db7d8ce780df5129b4d0f5bbf145271ef14f
(which is similar to what is done in Folly)

* x86-64 uses %rbx as the base register, so preserve it. */
#define __cpuid_count(__leaf, __count, __eax, __ebx, __ecx, __edx)             \
  __asm("xchgq %%rbx,%q1\n"                                                    \
        "cpuid\n"                                                              \
        "xchgq %%rbx,%q1"                                                      \
        : "=a"(__eax), "=r"(__ebx), "=c"(__ecx), "=d"(__edx)                   \
        : "0"(__leaf), "2"(__count))
        ```

[terrelln]

Thanks! I will backport that fix, and link the PR here. It would be great if you could confirm if it fixes your issue when you get a chance.

[terrelln]

@virt00l this is fixed by PR #3957, which is a direct backport from Folly.

We're about to make a release, and this was one of the blocking issues we identified for our next release. Please let me know if the issue persists after this change.