Are you interested to be listed as a maintainer of

Yes

Does not build without a new binutils on CentOS 8 it seems.

This is when trying to build LIBXSMM/master, right?
I am starting to believe this should be solved on LIBXSMM's side as well, i.e., providing a better user experience if Binutils are outdated (like automatically disabling the attempt to use related instructions). Please note, LIBXSMM's use case for these instructions is unrelated to JIT (which has no requirements in particular related to compiler or Binutils).

Indeed most compilers are now ahead of Binutils regarding target flags, which can lead to a situation where code is emitted which cannot be assembled by the (outdated) Binutils.

What part of binutils are you actually using? ld?

What part of binutils are you actually using? ld?

No particular part. None of the Binutils are actually invoked directly, just what the compiler invokes indirectly. The root cause is usage of some intrinsics (_mm_something ), which the compiler understands. However, the assembler (invoked indirectly by the compiler) does not know how to encode that instruction. Though, an intrinsic or even a textual assembly instruction must be encoded (brought to binary form). As a side-note, LIBXSMM's JIT code facility encodes instructions on it's own (not with the help of any compiler or Binutils). However, LIBXSMM also uses intrinsics in its code base (beside of most relevant code being jitted).

There is actually a solution already in LIBXSMM's build system to prevent such issue: make INTRINSICS=1. An alternative can be make INTRINSICS=1021. The former disables all function attributes/target flags that can cause such problem, and the latter limits such code paths to Cascade Lake. If I remember correctly, the latter is only available in master revision. I believe limiting to Cascade Lake is just enough for your case (CentOS 8), but make INTRINSICS=1 is wider available (since the beginning) and there is no harm for performance.

Note, instructions causing the problem are only related to LIBXSMM DL domain (Deep Learning), but most applications just rely on MM domain.

Hm, this is out of the scope of this PR, but I wonder whether spack can't be a bit smarter about using a newer binutils as a build dep for all/many packages by default. It already complains about the fact that GCC 8 cannot optimize for zen2, and that warning vanished when picking GCC 10, but we don't have a warning that system binutils might be outdated nor a way to configure what ld to use by default

Hm, this is out of the scope of this PR, but I wonder whether spack can't be a bit smarter about using a newer binutils as a build dep for all/many packages by default. It already complains about the fact that GCC 8 cannot optimize for zen2, and that warning vanished when picking GCC 10, but we don't have a warning that system binutils might be outdated nor a way to configure what ld to use by default

This is likely to happen going forward, but I would revisit the issue when we're at the point of turning compiler into proper dependencies. Regarding adding binutils as a dependency, it's currently not considered a best practice, see here.

Basically until we can reason around binutils requirements as part of compilers, I would just leave the configuration of a proper compiler to user. Wonder if @adamjstewart has more to say about that, or if he has different opinions.

The Binutils thing is sort of a "dark corner" since it is little known that Binutils are not part of the compiler (GNU GCC). This is actually different with Clang, Intel Compiler, and other compilers which typically march in lockstep with an assembler.

The FMA4 thing (LIBINT) is slightly different since FMA4 is orphaned and retracted from later µArch/CPUs; a better solution would be to just leave it aside (remove from LIBINT) and go for FMA/3, which is available just fine for all current CPUs that are capable of AVX2 (-mavx2 -mfma). The opposite of a safe path is to bet FMA4 is available in current CPUs (even if not advertised in CPUID flags). If LIBINT wanted to deploy FMA4 (for whatever reason), it better uses inline assembly instead of an intrinsic name that never got any traction (and likely fails to compile).

Historically, we've been wary of adding binutils as a dependency. Technically, just about every package in Spack requires binutils. A few like this package or numpy require newer versions than are found on some systems. This is all documented in https://spack.readthedocs.io/en/latest/getting_started.html#binutils.

In the long term, we've been talking for a while about how to get Spack to automatically bootstrap things like make, curl, patch, and other system commands. I'm not sure if any progress has been made on this. I wonder if binutils is something we would consider adding. I can also take a look at adding automatic external package detection.

Basically, I'm not sure if I approve of this PR, but I also don't disapprove of it and won't stop it from being merged.

@haampie Next release of LIBXSMM will avoid running into the problem with outdated Binutils. I have implemented a change in LIBXSMM/master which avoids this issue.

Ok, then I'll drop the dependency here