[PATCH] D48252: [MCA][NFC] Add generic TBM resource tests

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D48252#1134780, @RKSimon wrote:

> In https://reviews.llvm.org/D48252#1134779, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D48252#1134776, @RKSimon wrote:
> >
> > > LGTM thanks
> >
> >
> > Thank you for the review.
> >
> > Note that i don't //fully// understand the pattern here.
> >  I followed the basic idea that for every instruction, the last (destination) register should always be the same,
> >  the highest used register (i.e. if there is an instruction taking 3 registers, it would be `%rcx`).
> >  All others start from `0`/`a` always. And the memory operand is always 64-bit.
>
>
> The general rules I've been trying to keep to are:
>
> - Alphabetical order
> - Ascending register sizes
> - Avoid dependencies between instructions if possible (e.g. FMA3 failed here) - which I think is what you mean by register outputs the same?
> - Avoid repeating source registers (I got hit by this for xor zero idioms)


Ok, thank you, that all makes sense, and in this case it //seems// i followed those rules.
Will double-check the https://reviews.llvm.org/D48264.

> - Keep the address math as simple as possible (in case we start modelling AGU micro behaviour)
> - Try to avoid special cases that scheduler models might support some day (zero idioms again.....)
> - Keep copies of the resource files in sync
> 
>   I haven't done anything to check for different instruction encoding lengths, which might be a problem if we start modelling the frontend, although I have avoided the x64 registers if possible.
> 
>   Special cases should be tested locally for CPUs that care (zero/move idioms, macro fusions etc.) in their own files and not in the resource test files.




Repository:
  rL LLVM

https://reviews.llvm.org/D48252