[PATCH] D60000: [llvm-exegesis] Post-processing for chained instrs in latency mode (PR41275)

[Guillaume Chatelet via Phabricator via llvm-commits]

gchatelet added a comment.

It doesn't feel like the right approach to me.
`llvm-exegesis` is about relying on measurement to deduce informations. Here you're using a priori knowledge (SchedClass) which may be wrong.
To me, a better approach would be to read all the experiments, create the dependency graph between the 2-instructions snippets and solve a system of equations to recover the per instruction latency, then use the analyzer on the result.



================
Comment at: test/tools/llvm-exegesis/X86/analysis-latency-instruction-chaining.test:13
+# Thus, the real latency of the first instruction is the per_snippet_value minus
+# the sum of latencies of all the other instructions in the snippet.
+
----------------
In this paragraph it is unclear what `next instruction` refers to.

Maybe rephrase to something like "By constructions, snippet's instructions execution never overlaps. As a consequence the `per-snippet latency` is the sum of the latencies of the instructions in the Snippet. For instance, in the following example latency(BT32rr R11D R11D) + latency(RCR8rCL R11B R11B) = 12
"


================
Comment at: test/tools/llvm-exegesis/X86/analysis-latency-instruction-chaining.test:45
+    - 'RCR8rCL R11B R11B'
+    - 'RCR8rCL R11B R11B'
+  config:          ''
----------------
Just to be sure, you crafted this InstructionBenchmark for the sake of testing right?
I don't see how the current code generator can come up with three instructions.


================
Comment at: tools/llvm-exegesis/lib/PostProcessing.h:10
+/// \file
+/// Post-processing for the benchmark points.
+///
----------------
Maybe explain what post processing does. As such it is not too informative.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60000/new/

https://reviews.llvm.org/D60000