[PATCH] D74156: [llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE

[Guillaume Chatelet via Phabricator via llvm-commits]

gchatelet added a subscriber: orodley.
gchatelet added a comment.

In D74156#1864292 <https://reviews.llvm.org/D74156#1864292>, @lebedev.ri wrote:

> In D74156#1864096 <https://reviews.llvm.org/D74156#1864096>, @gchatelet wrote:
>
> > (registers of a class are not strictly equivalent [1])
>
>
> I //think// that currently can't be expressed in sched models - is that planned to change,
>  or we just want to know when we fail to model things?


Not in the sched models but in the target: X86FixupLEAs <https://github.com/llvm/llvm-project/blob/ea3a25e4f5166ccd5e523f0165f5270b24d71f46/llvm/lib/Target/X86/X86FixupLEAs.cpp#L295>.

>> - snippet generation (we always select the same pattern but exploring them would help [2])
> 
> which is //roughly// what `SerialSnippetGenerator::generateCodeTemplates()`/`appendCodeTemplates()` does,
>  but somewhat more general, correct?

yes

> This is not very useful until analyze learns to deal with serial chained instructions (D60000 <https://reviews.llvm.org/D60000>, stuck)

yes, @orodley is likely to work on this.

>> - repetition mode (to see the impact of the decoder)
> 
> This //appears// to be currently handled via `-repetition-mode` switch (D68125 <https://reviews.llvm.org/D68125>).

yes

> Does this really have to be accounted for (a dimension in) in the greedy approach?

@courbet and I believe that having two measures are better than one and can demonstrate the impact of decoding the instruction.

>> Code wise this means it would be much better to have a global sampler object
>>  responsible for how to explore these dimensions rather than the greedy approach we're heading to.
>>  Now I understand this is a substantial redesign and I'm not asking you to do it
>>  but I just wanted to share what I believe is the right direction to lower code complexity in the long run.
> 
> For context, we kind-of already explore condcodes/registers, by producing them randomly;
>  so if we run a lot of benchmarks, we're bound to explore them,
>  but without good coverage/reproducibility/repeatability though.
>  Which is why i'm starting with this patch - even greedy is better than what currently is.
> 
> So it's not so much that I don't want to redesign as though
>  I'm not sure i currently fully grasp  the idea behind "global sampler object".
>  How would that work?

So the `GlobalSampler`™ would be instantiated early (in the `main`). It would generate a single number (random or manually selected) which would be mapped to N dimensions (something like hilbert curve or z-curve).  The value would be passed down to each function that needs to randomize a choice so they can deterministically select the values.
Does this make sense?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74156