[PATCH] D60057: [llvm-exegesis] Handle CMOV's OPERAND_COND_CODE OperandType

[Guillaume Chatelet via Phabricator via llvm-commits]

gchatelet accepted this revision.
gchatelet added inline comments.
This revision is now accepted and ready to land.


================
Comment at: tools/llvm-exegesis/lib/SnippetGenerator.cpp:49
               : RATC.emptyRegisters();
       // TODO: Generate as many BenchmarkCode as needed.
       {
----------------
lebedev.ri wrote:
> courbet wrote:
> > lebedev.ri wrote:
> > > Any advice on how to best produce multiple variants covering all the condcodes?
> > > The obvious solution could be to pass `BenchmarkCode` to Target hook that would
> > > duplicate it for each of the possible condcodes,
> > > and return vector that would get appended to `Output`.
> > > Is that on the right track? Anything cleaner?
> > I think the original idea was to generate several identical templates and let randomization handle exploration. With what you just implemented when generating several instances of the same template you always get the same cond code because you wrote:
> > 
> > ```
> >  AssignedValue = llvm::MCOperand::createImm(1);
> > ```
> > 
> > if you did something like:
> > 
> > ```
> >  AssignedValue = llvm::MCOperand::createImm(random_int_in_range(0, 2));
> > ```
> > 
> > Then half of your generated snippets would go each way.
> > 
> > + @gchatelet who started[[ https://github.com/llvm-mirror/llvm/commit/b1497a74adb1d3669dbb16a9e02ee5214ea211a6 |  implementing support for exploration  ]].
> Hmm, yes, that is the least intrusive solution, but that is waay too brittle. :(
> Is that really the recommended solution here, given that we know all the affected opcodes and the possible condcodes?
Thx for the fix @lebedev.ri 
I'm not sure to understand what you mean by `waay too brittle`. Keep in mind that we want to explore as much as possible and - for sure - we can be more efficient when we know the semantic of a dimension but we also want to discover new behavior that were not known before.
There's a tension between the two obviously. For now I would just stick to this Patch. I'll work on value exploration as soon as possible - I'm especially interested in floating point values.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60057