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

[Guillaume Chatelet via Phabricator via llvm-commits]

gchatelet added a comment.

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

Yes.
Measurement ought to be coherent for runs on the same CPU so with enough data the resulting linear system will be over constrained and is solvable using ordinary least square (https://en.wikipedia.org/wiki/Ordinary_least_squares).

> How will that scheme will account for domain transfer delays?

You could associate a supplementary variable for pairs of instructions but this would need a lot of data to converge (way too many variables).
A simpler approach is to make sure that we don't generate domain transfer delays when generating the snippet, rejecting pairs of instructions for which it would occur.
Or annotate the results with information about domain transfer delays and deal with it in the post processing (adding variables for pairs in {int,vector,fp,store}² when we know such a transfer exist) this way we can recover the domain transfer delays as well.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60000