Updated for Vector integer classes (ZMM variants) as per @RKSimon comments!

Adjusted the resource cycles and retained the micro-ops as is as per @RKSimon comments!

Updated for review comments!

Updated for RKSimon's review comments as below.

Modified RMPADJUST instruction definition.

Updated the SNP instructions for the review comments!

In D141458#4043650, @RKSimon wrote:

Is it worth adding a SNP feature predicate to X86.td? Are they ever going to be exposed as intrinsics or just asm?

Fixed the tests

In D139073#3997418, @RKSimon wrote:

Thanks @GGanesh - LGTM with one minor - the orphan ZNVER4 checks from the llvm-mca tests need removing

Update to use 'no' processor model.
Fixed the below tests
tools/llvm-mca/X86/cpus.s
tools/llvm-mca/X86/read-after-ld-1.s
tools/llvm-mca/X86/register-file-statistics.s
tools/llvm-mca/X86/scheduler-queue-usage.s

In D139073#3995741, @RKSimon wrote:

@GGanesh reverse-ping

The following are the AMD Zen3 models.

In D94395#2729986, @lebedev.ri wrote:

@GGanesh thank you for taking a look.
1 nit addressed

In D94395#2729453, @GGanesh wrote:

In D94395#2728674, @lebedev.ri wrote:

@GGanesh i plan on landing this next monday, may 3'rd, in 3 days, unless some blocking feedback is provided.

I am fine mostly. Will give it another look and check the details.

Was that it?

In D94395#2728674, @lebedev.ri wrote:

@GGanesh i plan on landing this next monday, may 3'rd, in 3 days, unless some blocking feedback is provided.

In D94395#2717365, @lebedev.ri wrote:

In D94395#2717286, @GGanesh wrote:

Regarding the pipe events, the patch in kernel.org had just copy pasted events from zen1 and zen2. Apparently, I learnt that these events are restricted and at present not really ready for public for znver3. That is what is reflected in the kernel patch as well. If we notice, PMCx000 is incorrectly mapped and doesn't really count the 6 pipes.

Is that something that might be fixed via/in next microcode updates, or it's a hardware bug?

Regarding the pipe events, the patch in kernel.org had just copy pasted events from zen1 and zen2. Apparently, I learnt that these events are restricted and at present not really ready for public for znver3. That is what is reflected in the kernel patch as well. If we notice, PMCx000 is incorrectly mapped and doesn't really count the 6 pipes.
Is there any workaround that you guys suggest. I understand that these are pfm counters and are dynamic in nature. However, for the model, (at least for the throughput numbers) shall I publish our internal numbers running the internally enabled libpfm4 library? This is restricted in its immediate purpose which I understand however at present it may act as a work around for the throughput and llvm-mca numbers.
I am going through the modifications\corrections made in the by @lebedev.ri in the meantime.

The FPU pipe counters aren't in the PPR as well. I have raised a ticket so as to get this updated in the PPR. Unfortunately, without the document getting updated, these events can't be enabled.

My colleague had submitted the libpfm4 patch to the libpfm4 community. You can take this patch and enablement for exegesis for znver3. Thank you for the help!

We have exchanged mails with Eranian for libpfm4 support. We will upload the libpfm4 patch shortly (3-4 days in time). The patch will be based on the latest PPR manual (https://www.amd.com/system/files/TechDocs/55898_pub.zip). I believe that will keep it moving for verifying the numbers and the details with exegesis.

I can work on znver1 and znver2 models as well. I have a znver2 machine. Let me check if I can get a znver1 machine and run exegesis to correct these latency\throughput numbers.

We have started working on the libpfm patch. We are working on getting it posted very soon! Hopefully, once that is in place, we will be able to measure these numbers in znver3 hardware and correct accordingly.

I would like to know if this patch can be approved and later can be checked for the numbers when a cpu is accessible.
Since this is an extension and tweaks from znver1->znver2 path, I would request that if it is doable.

Ping!

The enhancement applies to specific string lengths. I will check it and if need be will submit changes with respect to this prerequisite.

Updated the patch for the review comments from @craig.topper and @pengfei

1. The instructions are updated for prefix specifiers
2. Except for pvalidate all the SNP instructions are valid only in 64-bit environment. Corrected the test accordingly.
3. The modes (In64BitMode, In64BitMode) are updated in Instruction description.

Updaing the patch so that the simplified patch adds only few missing znver3 tests. The subsequent patches will comprehensively enable other znver3 features.

In D92812#2439324, @RKSimon wrote:

it looks like a very bad merge imo.

Yep, Thank you! I will post smaller incremental patches.

@andrew.w.kaylor I went through the mailing list thread regarding this change and saw "Eventually, we’ll want to go back and teach specific optimizations to understand the intrinsics so that where possible optimizations can be performed in a manner consistent with dynamic rounding modes and strict exception handling.".
Do you have any references\plans on how to teach specific optimizations on this?

Good with me! I am have moved some stones to get the wikichip URL updated.

Yes looks good to me.

Changes done are obvious. Are you using libpfm with znver2 for verifying these?

RKSimon could you please commit D66088 on my behalf. I think my github account is not added.

We are checking the libpfm enablement. I can commit D66088 if we are okay without libpfm.

I agree on having a patch to enable exegesis. Will post that in couple of days. As mentioned, this is part of the initial plan as well.

Ping!

Ping!

Updated the patch for review comments.

Updated for review comments and latency modifications for MUL, vzeroupper, CLZERO instructions.

The changes for review comments are incorporated.
The latency information in CLZERO, VZEROUPPER, MUL instructions are updated.

Ping!

Addressed the comments from Craig Topper

LGTM!

I am fine!

LGTM!

Sorry! Missed this thread completely!
LGTM!

gcc uses feature bits. That would be a differential ISA with respect to the previous gen. I think the idea is to get the ISA list as close to the underlying arch. When an older version of the compiler gets used which doesn't have the arch enabled, the compiler can fallback to the closest arch which enables the ISA list.

It shouldn't differ.
The xmm version has 1 cycle latency and ymm version has 2 cycle latency for both AVX and SSE.

Looks good to me!

Updated for review comments from Craig Topper!

Simon! If you are okay with the patch, can you please commit the patch on my behalf!

Updated as per Javed's comments!

Updated the patch as per Simon's comments.
Added the FP instruction itineraries which includes SSE4A and SHA instructions.

Yes Simon! I will include the SSE4A instructions, their itineraries in the next patch. I will include tests verifying them as well.
If this patch is okay, can you please commit this patch on my behalf.

Simon, Craig Topper! My next increment is ready. If this patch can be accepted and committed, I will rebase and submit the next patch.
Or should I submit the next patch as an incremental patch with the changes put forth in this patch? Please help!

Updated for the itineraries of memory variants of the instructions.

Thanks all!

Simon! If you are fine, can you please commit the patch on my behalf. I am yet to get commit access rights. Probably, after this patch, I will try to get it.

Patch update: For newer testcases.

Updated as per Javed's review comments!