I can combine them to a single file.
The reason for the separation is to improve the ability to track the coverage.
Note that there is also the PPRO ISA set.

1. Added AVX tests for 32 and 64 bits.
2. Updated AVX2 64 bit tests to include xmm15 test in addition to xmm6 tests

ping

Removed duplicates per Simon's comment

following Simon's comment to add the retl scheduling information.

Good point.
From the tables I have, I could not find any scheduling difference between retl and retq they are both mapped to:
XED_IFORM_RET_NEAR
latency = 2 cycles + 5 cycles load latency.
3 uOps
ports: 23, 0156, 6

AVX2-32.s : Removed redundant # signs from AVX2-32.s
AVX2-64.s: Duplicated the tests to use XMM8 and YMM9

Ah, You mean the XMM registers.

You mean that each instruction should cover all registers?
I did a quick check and it produces a huge number of tests that exceed 200k including AVX512.
I, therefore, chose to use only representatives.

sorted the instructions per Zvi's comment

Removed old scheduling for the GATHER instructions which has overridden the new ones.
Fixed the overall load latency attribute for HSW from 4 cycles to 5.

good catch, The old scheduling has overridden the new one in the td file. I will update the diff file

Ah you're right. For SNB this is fine.
My comment was for HSW. Sorry.

Unfortunately, I cannot give you the exact numbers.
Overall, on ~900 benchmarks the performance speedup gain of new scheduling is ~6%.

Simon, splitting the instructions based on the CPUID bit is referred actually according to "CPU extension".
There are a total of 62 extensions.
I can do it according to extensions. The only problem with that is that it will complicate the generation of the tests.

I updated the list of ISA Sets.
I think we can consdier removing the REAL and the Protected ISA right?

Performance runs are done on 3 main benchmarks: SPEC CPU 2017, Geekbench4, EEMBC suite of automotive, denbench, coremark-pro, networking, telecom.

Please ignore my previous comment. These instructions are not used by the compiler Ring 1.
I will remove them from the ISA Set.

The BBX* ISA Sets are new AVX512 instrs. Here are some examples below (<format: #iclass, extension, category, iform, isa_set>:
VPSLCTLASTD, AVX512EVEX, BBX2, VPSLCTLASTD_XMMu32_MASKmskw_MEMu32_BBX, BBX2_128
VPSLCTLASTD, AVX512EVEX, BBX2, VPSLCTLASTD_XMMu32_MASKmskw_XMMu32_BBX, BBX2_128
VPSLCTLASTD, AVX512EVEX, BBX2, VPSLCTLASTD_YMMu32_MASKmskw_MEMu32_BBX, BBX2_256
VPSLCTLASTD, AVX512EVEX, BBX2, VPSLCTLASTD_YMMu32_MASKmskw_YMMu32_BBX, BBX2_256
VPSLCTLASTD, AVX512EVEX, BBX2, VPSLCTLASTD_ZMMu32_MASKmskw_MEMu32_BBX, BBX2_512
VPSLCTLASTD, AVX512EVEX, BBX2, VPSLCTLASTD_ZMMu32_MASKmskw_ZMMu32_BBX, BBX2_512
VPSLCTLASTQ, AVX512EVEX, BBX2, VPSLCTLASTQ_XMMu64_MASKmskw_MEMu64_BBX, BBX2_128
VPSLCTLASTQ, AVX512EVEX, BBX2, VPSLCTLASTQ_XMMu64_MASKmskw_XMMu64_BBX, BBX2_128
VPSLCTLASTQ, AVX512EVEX, BBX2, VPSLCTLASTQ_YMMu64_MASKmskw_MEMu64_BBX, BBX2_256
VPSLCTLASTQ, AVX512EVEX, BBX2, VPSLCTLASTQ_YMMu64_MASKmskw_YMMu64_BBX, BBX2_256
VPSLCTLASTQ, AVX512EVEX, BBX2, VPSLCTLASTQ_ZMMu64_MASKmskw_MEMu64_BBX, BBX2_512
VPSLCTLASTQ, AVX512EVEX, BBX2, VPSLCTLASTQ_ZMMu64_MASKmskw_ZMMu64_BBX, BBX2_512

Ok. The CLZERO instruction is going to be part of AMD ISA Set. It is very recent and part of of the Rizen CPU.

Do you mean the following LWP instructions that belong to the XOP ISA set?:
LLWPCB LLWPCB_GPRvqq
LWPINS LWPINS_GPRyqq_GPRvd_IMMd
LWPINS LWPINS_GPRyqq_MEMd_IMMd
LWPVAL LWPVAL_GPRyqq_GPRvd_IMMd
LWPVAL LWPVAL_GPRyqq_MEMd_IMMd
SLWPCB SLWPCB_GPRvqq

yes. SLM is good enough

Sorry. Here is a more readbale table of I486 + I486REAL:

I486 will include encoding + asm of the following instrs:

Unfortunately, I am using an internal DB with python scripts.

Updated diff after rebase

Note that WriteALU means 1 cycle latency using Port 0156

Updated diff file after adding the following instructions to the SKX scheduling file:
(V)MAXCPD/MAXCPS/MAXCSD/MAXCSS/MINCPD/MINCPS/MINCSD/MINCSS

Updated diff following Craig's comment.

This modified version of the SkylakeClient schedulings does indeed show gains on SKL without apparent regressions when compared to the existing SKL schedulings.
Thus, we are motivated to continue with the process of updating all X86 target schedulings.
Next step, once this patch is committed, is to submit the Broadwell schedulings for review.

Yes. The X86 Bit Test is known to run slowly on all X86 CPUs.

The .td file is actually generated by a script and if you notice it already contains some (not many) regular expressions when possible,
For the SKX scheduling, for example, there are many regular expressions that include the broadcast, mask and zeroing bits for all relevant AVX512 instructions.
The problem is that there are not many opportunities to group instructions into regular expressions.
For example, the MMX_* is spread between groups 1, 2,3,8,9,12, etc.
The differences between the groups could be in any of the latency, number of uOps or the ports used by the uOPs.
This makes it hard to use regular expressions.

Updated diff following Simon's comment to remove the COMMON check prefix from the bmi2 scheduling test.

Updated diff file after rebase,

Ping :-)

Good point. We had multiple rounds of checks and it seems that indeed some (not all) of the memory instructions do need to include additional latency based on whether they are load of an address or data, load of 128 or 256 or 512 bits vector, load and store and store alone.
I intend to go back and fix it for the Skylake Client and for Haswell.

Had to replace all test files with new ones as they were using the avx512 intrinsics which are now in the process of being replaced by IR.
As a result I created 2 new tests which were compiled from the following regression tests:

Updated diff after running update_llc_test_checks on the 8 tests and re-applying the changes to get rid of the "End of function" comments.

Updated diff after a rebase.