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

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri marked 2 inline comments as done.
lebedev.ri added a comment.

In D60000#1451313 <https://reviews.llvm.org/D60000#1451313>, @gchatelet wrote:

> It doesn't feel like the right approach to me.




In D60000#1451313 <https://reviews.llvm.org/D60000#1451313>, @gchatelet wrote:

> `llvm-exegesis` is about relying on measurement to deduce informations. Here you're using a priori knowledge (SchedClass) which may be wrong.


Yes.

> 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.

Can you explain that in a bit more detail? Something like

  lat(i_0) = m_0
  sum(lat(i_t)+lat(i_0)) = m_1
  lat(i_1) = m_2
  sum(lat(i_t)+lat(i_1)) = m_3
  ...
  lat(i_n) => ?
  sum(lat(i_t)+lat(i_n)) = m_n
  lat(i_t) => ?

Do you suggest to take known `lat(i_0)..lat(i_n)` from measurements too?
How will that scheme will account for domain transfer delays?



================
Comment at: test/tools/llvm-exegesis/X86/analysis-latency-instruction-chaining.test:45
+    - 'RCR8rCL R11B R11B'
+    - 'RCR8rCL R11B R11B'
+  config:          ''
----------------
gchatelet wrote:
> 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.
Yes, this is just a copy-paste.
As you can see, `assembled_snippet` is identical to the previous benchmark.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60000