This is an archive of the discontinued LLVM Phabricator instance.

[MCA][NFC] Add generic TBM resource tests
ClosedPublic

Authored by lebedev.ri on Jun 16 2018, 12:53 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

lebedev.ri created this revision.Jun 16 2018, 12:53 AM
RKSimon accepted this revision.Jun 17 2018, 3:27 AM

LGTM thanks

This revision is now accepted and ready to land.Jun 17 2018, 3:27 AM

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.

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

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

This revision was automatically updated to reflect the committed changes.