I don't see any changes for VEXTRACTF128 in tests. Do you really need this JWriteVecExtractF128? If YES you should add the corresponding test.

The issue with SB uops was fixed.

Now we have WriteCMPXCHGRMW accordingly to craig.topper requirement.

In D47196#1202805, @efriedma wrote:

:start: means the timer was started

In some cases, the ChildTime is already non-zero at the "start" point; what does that mean?

I fixed the issue with WriteCMPXCHGLd - tnx to craig.topper.

In D47196#1190377, @efriedma wrote:

I mean, which of the callers of startFrontendTimer() is calling it with a pointer to std::declval()?

The ability to produce debug output for 'ftiming' was added. As result now it's possible to check places where timers start/stop and for what functions it's being done (see changes in Utils.h).

I fixed sched parameters accordingly to craig.topper suggestions.

The code was re-based. We have 2 changed tests for SandyBridge (Generic). I did not find the proper numbers in Intel SDMs or on Agner site that's why I don't know what's beter the new results or the old ones. The old sched model does not use SBPort4 for memory ops and that looks strange for me. Could anyone help me with these tests?

Currently we have 93 warnings for X86 CPU models:

In D45619#1192803, @craig.topper wrote:

I'm unclear why the we would want to assign clang's FrontendTimesIsEnabled from inside CodeGenAction. If I'm understanding the intentions here, the goal was to add more timing infrastructure to clang. But if the enabling is tied to CodeGenAction, then doesn't that mean any new clang timers wouldn't work under -fsyntax-only?

The patch was rebased after D49912.

All last requirements were fixed.

In D49861#1187225, @RKSimon wrote:

I think you're almost there but D49912 must be completed and committed first

In D47196#1186460, @efriedma wrote:

"0.0040" is four milliseconds? You're probably crediting time incorrectly, somehow. Can you tell which FrontendTimeRAII the time is coming from?

The comment was added:

XADD*rr instrs were added: I did not add rm version because we should decide how to do it beter:

In D49861#1184028, @RKSimon wrote:

Tag XADD instructions with WriteXCHG as well?

The new tests were updated, xadd* tests were added.

The WriteCMPXCHGLd was implemented.

efriedma, I removed redundant RAII objects but I still have the following:

In D49861#1184028, @RKSimon wrote:

Tag XADD instructions with WriteXCHG as well?

Accordingly to efriedma suggestion I removed start/stopFrontendTimer where it's possible and inserted FrontendTimeRAII in several new places. As result the patch becomes bigger and bigger. And as another result I got output like here (on compiler bootstrap):
....
0.5920 (165) _ZSt7declvalv (*)
0.5960 (155) _ZSt7declvalv (*)
0.5960 (162) _ZSt7declvalv (*)
0.6000 (167) _ZSt7declvalv (*)
0.6040 (155) _ZSt7declvalv (*)
0.6040 (160) _ZSt7declvalv (*)
0.6040 (169) _ZSt7declvalv (*)
....
(the above is grep output from build log file)

In D49861#1178401, @lebedev.ri wrote:

The SLM & btver2 - are those placeholders, or those are real values from agner?

I updated the tests accordingly to Roman's request.

But of course you're right: we need such mca tests. I'll try to prepare such tests for XCHG* and CMPXCHG* instrs (I've just started to work with CMPXCHG*).

But we have a lot of XCHG tests in other places. For example:

WriteShiftDouble was removed, other comments were fixed.

efriedma, do you have any other comments/requirements?

I fixed all requirements from Simon - even the SLM test was fixed.

The main idea of this patch is implemented in D47763.

In D47637#1162704, @lebedev.ri wrote:

Anything to do to get this going? Or did this got replaced by some other differential? D48222?

We decided that this patch won't include memory versions of instrs that's why I simply fixed tiny requirements like "place of WriteBitTest" and "removing of the TableGen CodeGenSchedule diffs".

I removed the changes from D48222.

In D49477#1167804, @RKSimon wrote:

Drop the tablegen CodeGenSchedule changes

Comments from Simon and Roman were resolved.

I added required comments and did the required changes.

I replaced 'auto' with real types accordingly to Simon's request.

In D48222#1164782, @RKSimon wrote:

What happened to the BSWAP patch? Compared to BT (D49243) it should have been pretty trivial to implement.

In fact we have there very similar issues but even with rr versions: we should separate implementations for different sizes 16/32/64. I'm going to complete it tomorrow. But again - most probably it will be w/o memory operands support like in D49243.

Now we use WriteRes instead of *WriteResPair.
Folded versions of the intrs will be implemented in the next patches.

http://www.agner.org/optimize/instruction_tables.pdf, page 202, "Intel Haswell", "List of instruction timings and μop breakdown" appears to list all the BT* as having latency of 1.

I mixed columns for latency and throughput: latency is missed.

In D48222#1163492, @lebedev.ri wrote:

(Would be great if the checkbox 'done' in notes would be getting checked, too)

In D47196#1162321, @efriedma wrote:

Adding startFrontendTimer/stopFrontendTimer helps a little, but it's still difficult to match a given startFrontendTimer to the corresponding stopFrontendTimer because they're in completely different functions in some cases. Do they really need to be scattered like that? If they do, please add comments so someone reading the code can match them up.

Hi All,
I need your help!

It seems I fixed all issues raised by lebedev.ri. The open question is: should I remove the second check inside checkSchedClasses? I'm sure there is a way to get default values for such SchedWrites like WriteALU, WriteFAdd, etc. but I don't know at the moment how to do it. Please, help.

I renamed WriteBTr with WriteBitTest.
I could not add memory version of the instructions because there were some issues. For example, if we have

In D49243#1160224, @lebedev.ri wrote:

I'm assuming that you have run ninja check-llvm-tools-llvm-mca-x86 and it was ok. (the test coverage seems to be ok as-is.)

Now the patch keeps only infrastructure changes to produce new TableGen warns about sched models.

In D48222#1158585, @RKSimon wrote:

Please can you pul out the BSWAP change into its own patch for review?

I fixed all issues raised by efriedma: GlobalDecl(FD), function body, class names, etc. Many tnx for your help.

In D47196#1134185, @efriedma wrote:

Can you give an example of what the output looks like?

I fixed warns for BSWAP instrs (see changes in X86*.td files). If this approach is OK I'll fix other instrs.

At the moment we have the following warns for X86:

In fact we have the warnings for 2 Targets only:

In D48222#1150904, @RKSimon wrote:

@avt77 Next step is probably to start briefly collating the instructions causing the warnings and investigate how best to fix them (list them here, raise bugs etc.). The aim would be to see if we can remove ALL these warnings before we consider committing this patch - its probably time to add the maintainers for each target that has warnings so they can be investigated?

Now it's almost completed but should deal with deafult Latency value: hope to implement it soon. (The current version does not produce yet warning about identical uOps & Latency during compiler build: maybe it's OK?)

Hi! I was out for 2 weeks that's why I did not do anything here. Is it still interesting for you? I'm going to publish an update asap.
But the question is: how to get latnency/uop from CodeGenSchedClass ?

9>>! In D47766#1124708, @RKSimon wrote:

I really don't like the idea of a separate file - I think the models need to stay self contained. @courbet 's approach in D47763 seems a lot tidier

In D47763#1124797, @courbet wrote:

Introduce X86WriteRes(|Pair)Unsupported.

If I use one check only (" // Check if an instruction is always overriden (candidate for a new class?)") I see warnings for p9model only.
At the moment, I'm learning debug output related to generation of all these tables and hope to come up with some realistic logging soon.

Simon, I have some troubles with slack connection that's why I read your message only now :-( I'll back with answer asap.

In D47766#1124565, @courbet wrote:

Then I'm not sure if we win a lot from this as it makes things less explicit, though I agree that it slightly reduces code duplication.

Of course not. First of all, I suggest to put AVX2 and AVX512 instructions in separate files and to use them in models which don't support AVX2 and/or AVX512. Etc.

Obviously, the idea was to use one include file for all targets. But it did not work in the first version of the patch. Now I did a "dirty hack" in TableGen to be able to do it. It works for 2 CPUs and obviously it should work for others. The usage is very simply: the common include file should keep the common unsupported instructions while the specific onces should be inserted into the specific .td files.

And the last question. Again, in P9Model we have

Next, we have for P9Model only:

Something is wrong with current diagnostic. Fro example, we have