EESSI and Spack may detect different targets

[lorisercole]

Typically, EESSI should detect the host's architecture and select the best-match target among the available ones.
For example, for a skylake (non-AVX512) system, it will select the haswell software stack, since it does not have skylake one.
This guarantees compatibility and tries to maximize performance.

Spack will detect the host's architecture with archspec (see spack arch -t) and use it as build target by default (e.g. zen4).
If we declare external packages that were built for an ancestor of the detected microarchitecture (e.g. zen2), it will possibly reuse them in future zen4 builds. Although it may not maximize performance, this workflow works.
This is how spood should work as well: if EESSI provided only zen2 but we are using a zen4 system, Spack should be able to reuse the EESSI software stack while building for zen4.

However, it appears that EESSI and Spack do not use exactly the same mechanism to detect the host's architecture, and this can cause incompatibility problems.
For example in this CI run Spack detects a zen2 target, whereas EESSI selected the zen3 software stack. If we declare these EESSI external packages with target=zen3, as we should, Spack will not reuse them because they are not compatible with the host architecture (and Spack is configured to build for the detected host architecture, by default, unless explicitly demanded by the user).

The real impact of this issue is probably very limited in practice, but a mapping EESSI-targets <--> Spack-targets should be carefully implemented in the future.
This also applies to cases like Nvidia-Grace (EESSI: aarch64/nvidia/grace), that is identified with the more general neoverse_v2 in archspec/Spack.

[lorisercole]

I think that archspec just checks the output of lscpu and uses a hard-coded mapping (see this JSON: archspec-json/cpu
/microarchitectures.json).
I've already seen cases where archspec seems to restrictive, in the sense that it expects too many CPU flags for a given target (like your CI case: it's probably a zen3 CPU but lacks one of the zen3 flags that archspec expects).

One simple and conservative solution could be the following. Let's assume that A < B means that microarchitecture B is a "descendant" of A, for example: haswell < skylake or zen2 < zen3. Then:

• if eessi_target <= spack_target: we can keep target=eessi_target, it's probably safe (assuming the archspec's target identification is always more restrictive than EESSI's one)
• if eessi_target > spack_target: (like in your CI) it means there is an identification mismatch, so we set target=spack_target to ensure that packages will be reused.

[ocaisa]

I can't foresee a problem with "lying" to Spack if you are only dealing with the local host, if EESSI (in theory) guarantees that the code it ships will run on your CPU then a white lie is never going to cause an illegal instruction.

I guess the problem arises if you ever try to push this back to a Spack build cache, at that point your information is tainted and you should have made the most conservative choice (probably based on the fixed mapping).