Find a sustainable way of handling CPU feature detection

As @ansgar mentioned in https://lists.dune-project.org/pipermail/dune-devel/2019-June/002456.html, the current way of detecting the CPU instruction set does not really work, as it just uses the CPU name. !46 (merged) is a quick workaround, but we need a proper fix.

mentioned in merge request !46 (merged)

dune-common's add_dune_vc_flags should probably get an option to /not/ append ${Vc_ALL_FLAGS} to the compile options and the CI system should enable that option (at least most of the time).

I kind of understand the motivation: the default would be only SSE2 on x86-64, although nearly every relevant system should have SSE3 and even SSE4. Enabling these always is probably okay. But we can't assume every system is capable of AVX-{2,512} (yet).

@joe: What do you think? (And can one ping non-project members with comments?)

The fact that Vc fiddles with the architecture flags is a WTF that has annoyed me for some time. IMO it should just work with whatever the compiler supports with the flags that the user specifies. And if the user does not specify anything, that means SSE2 on x86-64. If the user wants the best his current system supports, he can always specify -march=native.

I'll have a look if either FindVc or add_dune_vc_flags can be adapted.

(And, yes, @-ting non-members seems to work, I got notified about your comment, but not about the original issue)

Alright, find_package(Vc) seems to set the following cmake variables on epic (list was taken from here)

-- Found Vc: /usr/lib/libVc.a (found version "1.3.3") 
Vc_FOUND=<1>
Vc_INCLUDE_DIR=</usr/include>
Vc_DEFINITIONS=<>
Vc_COMPILE_FLAGS=<-Wabi;-fabi-version=0;-fabi-compat-version=0;-ffp-contract=fast>
Vc_ARCHITECTURE_FLAGS=<-march=znver1;-msse2;-msse3;-mssse3;-msse4.1;-msse4.2;-msse4a;-mavx;-mfma;-mbmi2;-mavx2;-mno-xop;-mno-fma4;-mno-avx512f;-mno-avx512vl;-mno-avx512pf;-mno-avx512er;-mno-avx512cd;-mno-avx512dq;-mno-avx512bw;-mno-avx512ifma;-mno-avx512vbmi>
Vc_ALL_FLAGS=<-Wabi;-fabi-version=0;-fabi-compat-version=0;-ffp-contract=fast;-march=znver1;-msse2;-msse3;-mssse3;-msse4.1;-msse4.2;-msse4a;-mavx;-mfma;-mbmi2;-mavx2;-mno-xop;-mno-fma4;-mno-avx512f;-mno-avx512vl;-mno-avx512pf;-mno-avx512er;-mno-avx512cd;-mno-avx512dq;-mno-avx512bw;-mno-avx512ifma;-mno-avx512vbmi>
Vc_SSE_INTRINSICS_BROKEN=<false>
Vc_AVX_INTRINSICS_BROKEN=<false>
Vc_XOP_INTRINSICS_BROKEN=<false>
Vc_FMA4_INTRINSICS_BROKEN=<false>
-- Configuring done

We should be fine to just use Vc_COMPILE_FLAGS in place of Vc_ALL_FLAGS in add_dune_vc_flags(). I'll try that on dune-common.

mentioned in commit core/dune-common@c0bbf1a5

mentioned in merge request core/dune-common!677 (merged)

Or just use none of them? -ffp-contact=fast is the default anyway (on GCC) and mangling with ABI parameters isn't something one should do by default either (IMHO). Though -fabi-version=0 is, again, the default as well (on GCC)...

On older GCC you had to pass -fabi-version=5 (or was it 6? And no, I don't precisely remember the problems that would occur it it was not specified). 0 just means newest on recent enough gcc AFAIR.

But I'm building a test for core/dune-common!677 (merged) anyway right now, I suppose I can just try and run it without those options too.

mentioned in commit core/dune-common@49cb2f53

mentioned in merge request core/dune-common!679 (closed)

@ansgar I'm going to merge core/dune-common!677 (merged) so this issue gets fixed quickly and !46 (merged) can be reverted. I'm going to have a look into core/dune-common!679 (closed) (which also skips Vc_COMPILE_FLAGS) and whether I can reproduce the issues with -fabi-version that I remember afterwards.

@joe: Thanks. Maybe this is the relevant change for -fabi-version? "Version 4, which first appeared in G++ 4.5, implements a standard mangling for vector types."

Possibly... I think it might have been Vc's cmake stuff that was complaining about this... I'm gonna keep looking in core/dune-common!679 (closed)

Well, I found the issue. Basically, at least some form of -fabi-compat-version is needed as long as we support gcc 5. Thus I closed core/dune-common!679 (closed).

mentioned in commit core/dune-common@19557065

mentioned in issue core/dune-common#165 (closed)

gna The Vc part works now, but OpenBLAS has a similar problem (https://bugs.debian.org/930482)...

I now set OPENBLAS_CORETYPE=sandybridge in the CI runner environment which makes dune-istl's tests pass again. Not nice, but at least it works.

mentioned in merge request core/dune-common!680 (merged)

I was thinking about reverting !46 (merged), but came to the conclusion that it is best to keep it in, even though it was originally meant as a workaround. This way, the CI should still work for older branches.

Unless we want to backport everything, of course...

I am not aware of any remaining issue, so as far as I'm concerned this can be closed (I don't have permissions to do so myself)

mentioned in issue core/dune-istl#93 (closed)

mentioned in merge request !62 (merged)

mentioned in commit 5cf2d3b3