[all-commits] [llvm/llvm-project] 294bee: [LoongArch][NFC] Consistently derive instruction m...

[WÁNG Xuěruì via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 294bee106589a8ec94e9a75f435698a478147aee
      https://github.com/llvm/llvm-project/commit/294bee106589a8ec94e9a75f435698a478147aee
  Author: WANG Xuerui <git at xen0n.name>
  Date:   2023-07-18 (Tue, 18 Jul 2023)

  Changed paths:
    M llvm/lib/Target/LoongArch/LoongArchFloat32InstrInfo.td
    M llvm/lib/Target/LoongArch/LoongArchFloat64InstrInfo.td
    M llvm/lib/Target/LoongArch/LoongArchFloatInstrFormats.td
    M llvm/lib/Target/LoongArch/LoongArchInstrFormats.td
    M llvm/lib/Target/LoongArch/LoongArchInstrInfo.td
    M llvm/lib/Target/LoongArch/LoongArchLASXInstrFormats.td
    M llvm/lib/Target/LoongArch/LoongArchLASXInstrInfo.td
    M llvm/lib/Target/LoongArch/LoongArchLSXInstrFormats.td
    M llvm/lib/Target/LoongArch/LoongArchLSXInstrInfo.td

  Log Message:
  -----------
  [LoongArch][NFC] Consistently derive instruction mnemonics from TableGen record names

The recent D154183 and D154195 have introduced a simpler way to specify
instruction mnemonics: by leveraging TableGen's `NAME` and string
processing features, the mnemonics can be automatically derived from the
respective TableGen record names. LoongArch instructions don't have
"strange" characters in their names, so this approach can be applied to
all the other instructions.

A `deriveInsnMnemonic` helper class, modeled after the LSX/LASX mnemonic
derivation logic, has been added, and all non-pseudo instruction formats
are converted to use it, losing their `opstr/opcstr` arguments in the
process.

There are minor differences that are worth mentioning though:

* The atomic instructions with implicit data barriers have an underscore
  (`_`) in their mnemonics, that will get converted to a period (`.`) if
  not specially handled. Double-underscore (`__`) in record names are
  converted to a single underscore in the resulting mnemonic; the
  definitions are tweaked accordingly.
* Various duplicated FP instructions need special handling, mainly
  because of the need to handle both FPR32 and FPR64 classes for a
  single hardware instruction. The substrings `_xS`, `_xD` and `_64` are
  additionally dropped before deriving FP instructions' mnemonics.

All of these are pure refactoring, no functional change.

Reviewed By: SixWeining

Differential Revision: https://reviews.llvm.org/D154916