[X86] Better testing of schedule model instruction latencies/throughputs

[RKSimon]

Bugzilla Link	32216
Resolution	FIXED
Resolved on	Dec 10, 2018 08:35
Version	trunk
OS	Windows NT
Blocks	#31672
CC	@adibiagio,@topperc,@filcab,@rotateright

Extended Description

We don't currently do a very good job of testing the various costs of instructions based on the specific schedule model used (generic, atom, sandybridge, haswell, silvermont, jaguar).

To help improve this it would be useful to have an option to to output assembly comments that indicate latency/throughput etc. of each instruction. We should then create a set of test files that cover a decent range of instructions.

[RKSimon]

Added SSE1, SSE2, SSE3, SSSE3, SSE41, SSE42 and AVX1 latency/throughput tests for 'generic', Atom, SilverMont, SandyBridge, Haswell and Btver2 (Jaguar) scheduler models.

[RKSimon]

We now have full instruction coverage for AES, AVX2, BMI, BMI2, F16C, LZCNT, MOVBE, POPCNT, SHA and SSE4A features. PCLMUL is included in the SSE42 tests.

There are also partial tests for FMA and LEA, which are mainly limited by the difficulty with guaranteeing we can generate every version of each instruction.

We don't check every cpu-target with a model attached, but every model should be tested at least once if the target supports a given feature.

[llvmbot]

One of the BLAS libraries recompiles, runs, and times each routine something like 100 times with different alignments and instruction set extensions to detect optimal cache line alignments and orderings (for the machine it runs on, of course, they claim to have noticed microsecond differences in the same proc family). We don't need to go that far, but a suite that could not only output comments but run a reduced set of this kind of testing to detect errata in schedules and uncaught pipeline / cache stalls for a particular family would allow the model to be improved in the scheduler at the cost of the running tons of tests once a month or so.

[RKSimon]

A lot of that work has been done by Agner already, and, personally, I don't have a problem trusting his numbers and using those directly in the scheduler models.

Although there are sometimes minor discrepancies between those and the official AMD/Intel docs, I've never seen anything truly concerning that isn't an obvious typo on one side or the other.

[RKSimon]

Resolving this - we have good test coverage thanks both to the llc "sse-schedule.ll" and the llvm-mca "resources-sse1.s" style tests.

Additionally, llvm-exegesis is helping us isolate schedule model errata.

[RKSimon]

mentioned in issue #31672