5

I need to disable all AVX512 extensions in gcc-compiled code. The reason is that Valgrind chokes on AVX512 instructions. Is there a way to do it with a single flag?

I know how to disable each extension individually (-mno-avx512f, -mno-avx512pf etc) but this is troublesome because different gcc versions support different subsets of those.

I use CMake. If there is a way to automate the flags with CMake machinery, this would also work for me.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
n. m. could be an AI
  • 112,515
  • 14
  • 128
  • 243
  • None are enabled by default, are you using `-march=native` maybe? – Marc Glisse Mar 23 '20 at 21:43
  • @MarcGlisse Yes, I'm using `-march=native`. – n. m. could be an AI Mar 23 '20 at 22:31
  • 1
    @MarcGlisse: is it officially documented anywhere that `-march=native -mno-avx512f` is guaranteed to also disable AVX512VL, AVX512DQ and so on? As the OP points out, my answer is right in current GCC but https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html doesn't guarantee it. – Peter Cordes Mar 24 '20 at 00:25
  • It seems to me that instead of enabling avx512 (march=native) then disabling it, it would make more sense not to enable it in the first place (march=skylake maybe?). If you want some guarantees about mno-avx512f, you need to ask in gcc-land, I am not so familiar with that part. – Marc Glisse Mar 24 '20 at 07:32
  • @MarcGlisse I do want other speedups that `-mnative` offers. It is not easy to enable them one by one for different CPUs. – n. m. could be an AI Mar 24 '20 at 08:18
  • @n.'pronouns'm. `-march=native -mno-avx512f` on a Skylake-SP or Cascade Lake is I think exactly identical to `-march=skylake`. Possibly a different L2 cache size tuning parameter for the `-mtune=native` part. However, going forward as more different CPUs come along there won't be easy equivalents; e.g. icelake-client / server both have AVX512 and might have some tune settings different from skylake. So I'd recommend using `-march=native -mno-avx512f`. The only case it's a problem for you is when it breaks noisily in cachegrind, so if future GCC changes (unlikely) you can change your build. – Peter Cordes Mar 24 '20 at 10:04
  • 1
    @PeterCordes Yes that's what I've ended up with. Frankly I would rather prefer avx512 and everything else just supported in valgrind, but one can dream... – n. m. could be an AI Mar 25 '20 at 21:13

1 Answers1

11

gcc -mno-avx512f also implies no other AVX512 extensions. AVX512F is the "foundation", and disabling it tells GCC the machine doesn't decode EVEX prefixes.

Similarly, -mno-avx disables AVX2, FMA3, and so on because they all build off of AVX. (Because of the way GCC works, -mavx512f -mno-avx might even disable AVX512F as well.)

e.g. gcc -march=icelake-client -mno-avx512f will reject intrinsics for AVX512DQ or AVX512VL instructions and so on, as well as not using them when auto-vectorizing.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • Hmm you seem to be right but is this documented somewhere? – n. m. could be an AI Mar 23 '20 at 22:42
  • @n.'pronouns'm.: I checked https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html but it doesn't seem to mention it. At least it's documented here, in my answer; I upvoted your question since it seems to not be something you can easily / at all look up elsewhere. – Peter Cordes Mar 24 '20 at 00:22