Where compiler code is going to get really unusual, I suspect, is that compilers tend to be a little mono-focused on relatively few data structures. I know I was able to get measurable (single-digit percent!) performance differences in LLVM making very small tweaks to layout in llvm::Value. By contrast, when I was working on Thunderbird, the only similarly small change I could think to make that kind of difference would be to "oops, all string functions are now a cross-DLL call" (and even then, only because string handling is so dominant in that kind of application). Another kind of difference is that the compiler-based benchmarks are going to be quite light in virtual or indirect function calls (there's more of an emphasis on switch-based dispatching than vtable-based dispatching in most compiler implementations), which is going to make it a poorer proxy for some kinds of applications.
If you're solely interested in single-core performance, then I would agree that they are a good stress test, but I think for a processor that is being sold on it's parallelism, they are not a great benchmark.
The reason is that for the other benchmarks the CPU vendors have always succeeded sooner or later, to tweak their compilers and compiling options, or even the hardware of the CPUs, in order to get improved benchmark results that nonetheless are not indicative of the improvements in other applications.
On the other hand, the compiling benchmarks, like with gcc, and now also with clang, are too diverse in CPU resource usage and no special feature of the CPU has a significantly greater weight than others, so special tricks to enhance the benchmark results have never been found.
When looking at the past SPECint results, the values of the gcc benchmark remain the most reliable relative performance estimator.
I doubt that this will change in the near future.
Moreover, the multi-threaded compiling benchmark is also very useful, because it matches exactly a real-world workload that is extremely frequently encountered. Due to the great clock frequency difference between running a benchmark on a single thread and running it on all available threads, the single-threaded results have a very poor correlation with the multi-threaded results.
That is, nowhere.
Also you are wrong and anyone sizing up an arch to put their loads onto must first try that load on it and not rely on "bah, compilers compile on it".
Remember, the very first Windows XP 64 bit release was on Itanium.
[1] https://archive.org/details/NT351PMZPPC
[2] https://www.techmonitor.ai/technology/undercurrent_bubbling_...
[3] Legend has it that the SPARC port existed, done by Intergraph, but for Reasons was never a product.
I'm not completely convinced of this.
If you ignore VLIW, you just have a very unexciting RISC ISA, but because of the VLIW, you get extra scheduling info that most RISC designs don't provide which might be advantageous. The real question is actually about the code density of 41-bit instructions and if it can be offset by the 128-bit package (and perhaps something like allowing new 24-bit compressed instructions).
Poulson already somewhat proved part of this as it added back a traditional frontend and even added some OoO capabilities and 4-way SMT. It wasn't earth-shattering, but it wasn't absolute garbage either.
The Itanium ISA actually had a few nice features, but it also had other bad features that outweighed the good features. Besides the static instruction scheduling in bundles, there was also the handicap of using SPARC style register windows, which slowed-down context switches.
The second version of HP PA-RISC, which was too quickly replaced by Itanium, would have had good chances of providing superior performance in comparison with Itanium, had it not been abandoned without a fight.