> able to tune the optimization for the CPUs of the newest of those reviews.

I see what this discussion is about, and it's again a lot of nonsense by people who haven't done their due diligence in testing or actually practised what they preach.

What you refer to as "tune" are the mtune setting or specifically the scheduler models fed into the compilers. Irrelevant of if we're talking about LLVM or GCC, these are almost completely irrelevant to the performance of a run and any variations are within the margin of error on the geomean score.

The decision to do ISO binaries on the -march=x86-64 -mtune=core-avx2 -mfma -mavx -mavx2 was because that was the subset that performed the best on all platforms within margin. On a Zen CPU running -mcpu=zen2/3 didn't make any difference in performance over 0.5% on the geomean, and while there's some difference in subscores they were a mish-mash of improvements as well as regressions.

> the compilation was made for a Haswell, even if the target was an Ice Lake

Because I did that and it doesn't make any difference in performance.

> the best available compiler should have been chosen on each platform, and on x86 I doubt that clang is that.

The value of having the same compiler that enables the same high-level optimisations on mobile devices, macOS, and Windows/Linux is of higher priority in the client SPEC numbers than the small GCC uplift. The GCC vs Clang performance difference were +2.5% for int2017 and +1.1% for fp2017. All the server SPEC numbers published were on GCC because that was the priority target for that environment and because there's little point in comparing a laptop to a server.

> So if an old clang version has been used for all x86 CPUs, the newer must have been disadvantaged.

Again, you speak theories instead of having verified this. It's just not the case.

> applying the benchmark rules, i.e. using the best compiler with the best options, for each CPU.

The benchmark rules state no such thing. I would suggest familiarising yourself with them.