Disabling all AVX512 extensions

Question

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.

Glindaglinka

None are enabled by default, are you using -march=native maybe? – Yonina

@MarcGlisse Yes, I'm using -march=native. – Glindaglinka

@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 gcc.gnu.org/onlinedocs/gcc/x86-Options.html doesn't guarantee it. – Stock

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. – Yonina

@MarcGlisse I do want other speedups that -mnative offers. It is not easy to enable them one by one for different CPUs. – Glindaglinka

@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. – Stock

@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... – Glindaglinka

Answer 1

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.

Stock

Hmm you seem to be right but is this documented somewhere? – Glindaglinka

@n.'pronouns'm.: I checked 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. – Stock