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

[Guillaume Chatelet via Phabricator via llvm-commits]

gchatelet added a comment.

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

> We don't want to use latencies of instructions specified in scheduler profile, but at the same
>  time we are ok with expecting that the sched profile explains all the domain transfer delays.

We want the tool to be as generic as possible to target other platforms but some decisions are to be target specific (e.g. the stack based registers of x87)
This is why `llvm-exegesis` relies on `ExegesisTarget` in `llvm-exegesis/lib/Target.h`.
As such it makes sense that the measurement tool is customized based on what we know or suspect about the target.
On the contrary it is a desirable property that the analysis tool to not depend on target knowledge as much.

> They should probably also be variables, not hardcoded. But i admit i have not thought that part through.

This was one of the suggestions I made (DTD being variables), I agree this needs to be thought through.

> In the same thoughtflow, would be great if it could try to magically deduce the actual Units (*not* just pressure distribution)

That would be nice indeed although nothing obvious comes to mind. We only have Hardware performance counter and code Snippets to recover knowledge.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60000