[Interest] good-compromise compatibility setting for -march=??? option (x86)?
Thiago Macieira
thiago.macieira at intel.com
Tue Jul 21 00:49:12 CEST 2020
On Monday, 20 July 2020 14:56:24 PDT René J.V. Bertin wrote:
> Thanks, will try though
> [https://en.wikichip.org/wiki/intel/microarchitectures/silvermont] suggests
> that Silvermont has the rdrand instruction that my i7 doesn't have.
It's supposed to have:
$ sde64 --help | grep Silvermont
-slm Set chip-check and CPUID for Intel(R) Silvermont CPU
$ sde64 -slm -- cpuid -1 --leaf=1 | grep RDRAND
RDRAND instruction = true
[http://www.intel.com/software/sde]
But some CPU features relating to crypto are sometimes disabled, either on
BIOS or on particular SKUs. So far, I'd only heard about the AES and
PCLMULQDQ[*] instructions, but I suppose RDRAND and RDSEED fit into that
category, as will the SHA, VAES and VPCLMULQDQ instructions.
To fix a Qt build, you can always append -mno-rdrnd to the build options. This
will disable the unconditional use of RDRAND in qrandom.cpp.
GCC's -march=native should use the feature set coming from your CPUID
instruction. So it should not enable RDRAND if your CPU doesn't report it.
That means -march=native may result in a feature set that matches none of the
other -march= options. You can check like this:
gcc -dM -E -march=native -xc /dev/null | grep RDRND
That does not apply to Clang. Clang's -march=native tries to find the best
match to your processor and then enables that particular entry. That means it
could enable features your processor doesn't have. If that's the case, please
report a bug.
I had to fix both GCC and Clang on the AES instructions. We may need to do the
same for RDRAND.
[*] pronounced "pickle-muckle-duck"
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
More information about the Interest
mailing list