Re: [PATCH][X86_64] Separate znver4 insn reservations from older znvers

[Jan Hubicka <hubicka@ucw.cz>]

> 
> On Tue, 3 Jan 2023, Jan Hubicka wrote:
> 
> > > 	* gcc/common/config/i386/i386-common.cc (processor_alias_table):
> > > 	Use CPU_ZNVER4 for znver4.
> > > 	* config/i386/i386.md: Add znver4.md.
> > > 	* config/i386/znver4.md: New.
> > OK,
> > thanks!
> 
> Honza, I'm curious what are your further plans for this, you mentioned
> merging znver4.md back in znver.md if I recall correctly?

I was looking into that over Christmas (and it was also reason for my
first pass through where I was asking for various differences).  There
are number of small divergences between znver.md and znver4.md that seem
to make the merged automaton bigger than having two automatons.
So merging both meaningfuly would mean modifying znver1-3 model or
znver4 models.  With Tejas I think we mostly verified that the areas
znver4 modes is different from znver1-3 are correct for znver4 and
sometimes also for znver3 (for example the branching unit is present
already there but not bodelled).

Splitting znver1-3 and 4 is definitly not optimal.  However given the
time constrains and desire to not break znver1-3 I think going with
znver4.md is good option at least for GCC12/13.

Overall I am not sure how beneficial the model overall is:
since we schedule on BB basis and model CPU as in-order with no register
renaming, the scheduler has rarely chance to fill most of execution
units and de-facto optimizes for wastly different CPU than reality is).
We get noticebale SPEC perfomance boost for -fschedule-insns2 but it
seems to be mostly for scheduling for latencies.
LLVM's model seems to do more than we do, but comparing both compilers
I was not really able to tell if either of them get noticeable benefit
from the actual model of reservation units (and not only latencies).

I would welcome toughts/ideas/measurements on this.
Honza
> 
> Alexander