Using gcc, is -march=native forwards compatible?

0
votes

We have a cluster consisting of machines that have the following CPU's:

  • Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz,
  • Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz,
  • Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz.

These support different instruction set extensions (e.g. the E5-2680 v3 has AVX2 and the others do not). Is -march=native forwards compatible such that code compiled with it on the oldest machine will run on the later models, or should one manually figure out the lowest common denominator?

The gcc version is 4.8.2.

2
gcc
The question is really about Intel processors / architecture and not really related to gcc... - Marc Glisse
What you want is a CPU dispatcher. Compile the dispatcher for the lowest common denominator. Then compile different object files for each hardware set you want to support and have the dispatcher choose the appropriate version. - Z boson
Thank you. I agree this is probably not the right place to ask this question since it relates to a specific set of (Intel) CPU's. But the CPU dispatcher option is definitely interesting. I'll have a look at it. - Pim Schellart
I'm voting to close this question as off-topic because it relates to specific architecture compatibility issues and not gcc in general. Sorry.. - Pim Schellart

2 Answers

0
votes

Is -march=native forwards compatible such that code compiled with it on the oldest machine will run on the later models

In general, no. There is no guarantee that an arbitrary newer chip will have all the instructions present on some arbitrary older chip. Using one of GCC's named -march option would be safer, because newer families tend to be supersets of older ones, but -march=native isn't generally safe to use that way.

For these specific chips, I think it should be OK to use -march=native but why risk it? Either enable individual instructions sets with options like -msse4.2 -mavx or use a named option.

With a modern GCC you could just use -march=sandybridge which matches the first two, and doesn't use any instructions not supported by the third one (which I think matches -march=haswell). For GCC 4.8.2 -march=corei7-avx should work for all of them.

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html shows which instructions are enabled by each -march option, or for GCC 4.8.2 https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html lists them.

0
votes

This is probably not the answer you are looking for.

I remember when I once compiled on a system that has a CPU with avx2 (intel 4th gen core i) with -mavx2 and used avx2 specific intrinsic according to Intel's C++ intrinsic guide and ran that executable on a different system that has a CPU (intel 2nd gen core i) that doesn't have avx2 instruction support, it ran absolutely fine. All calculations were fine. I only used the simplest calculation - added two variables each containing 8x 32-bit integers and showed the results on console.

But that tells us that Intel makes backward compatible system in this case. I am guessing this is because register size is same 256-bit on both CPUs.

I think as long as the register size is same or bigger, the BIOS made by Intel should provide forward compatibility in microcode; that's one of the main function of microcode on desktop/laptop based PCs.