[Interest] good-compromise compatibility setting for -march=??? option (x86)?

[Thiago Macieira]

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