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

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

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

> > Intermediate issue to solve: creating all these 2-instr chained configs must then also
> >  create configs to measure the params of that second instr (without going into endless loop).
>
> Yes it's more work and potentially really long runtimes. The randomization part is here because the original design was to run `llvm-exegesis` on many machines and aggregate the runs to do the analysis. The more data the better so we can test our hypotheses.
>
> >>> 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.
> > 
> > Hmm, i don't mean to mock
>
> Then don't. The mere fact you're mentioning it is already suspicious :)
>
> > but it sounds kinda hand-wavy/arbitrary.
>
> I offered three paths to explore, I don't know yet if they work, nor which one is best.
>  I'd need to dedicate some time to this but I don't have much right now TBH.


Any kind of approximate time estimate on this?
Next month? This release cycle? Next year? "some day, once there is time"?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60000