[Bug target/119010] [15 Regression] 444.namd shows a huge compile-time regression with -mtune=znver5

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119010

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #5)
> I had patch to reduce max issue back to 4 (exactly because of the compile
> time slowdown and because the way we model decoder we own't issue more than
> 4 instructions).

Btw, the decoder can indeed not saturate the 6 issue width (but decode
4 insns per thread), but the uop cache can issue 6 uops per clock per thread
and the OOO scheduler can dispatch 8 uops per cycle (for both threads).

So it's a good question what we model and whether that makes sense.  We do
seem to model the actual issue ports, but that's after OOO, but as we
schedule what gets into the decoder there's quite some intermediate magic
happening...  I suppose we can argue we optimize code layout for the
case of a uop cache miss (rather than for example for best uop cache
occupation or 6-wide issue from that).  Btw, you can actually benchmark
with the uop cache turned off (see
https://chipsandcheese.com/p/disabling-zen-5s-op-cache-and-exploring for which
MSR to tick) - might be an interesting
thing when tuning the scheduler.