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

What i'm saying is that it is pretty much known as a fact that LLVM (at least on X86?) has (very?) partial modelling
of these extra delays, so if we take as granted that all of them are already modelled, the post-processing
may produce rather misleading results.

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

ack

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

ack


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60000