[all-commits] [llvm/llvm-project] 5713c2: Update "Writing a Backend" doc to use named operan...

James Y Knight via All-commits all-commits at lists.llvm.org
Wed Oct 26 11:06:36 PDT 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5713c2959cdd56b8d529d71a078981de1333a5f4
      https://github.com/llvm/llvm-project/commit/5713c2959cdd56b8d529d71a078981de1333a5f4
  Author: James Y Knight <jyknight at google.com>
  Date:   2022-10-26 (Wed, 26 Oct 2022)

  Changed paths:
    M llvm/docs/WritingAnLLVMBackend.rst

  Log Message:
  -----------
  Update "Writing a Backend" doc to use named operand matching.

This brings it in line with recommended practice after the
introduction of sub-operand naming in a538d1f13a13, and the
deprecation of positional argument matching in 5351878ba196.


  Commit: 23394cd81092b10fea92a9e3959354865082fad1
      https://github.com/llvm/llvm-project/commit/23394cd81092b10fea92a9e3959354865082fad1
  Author: James Y Knight <jyknight at google.com>
  Date:   2022-10-26 (Wed, 26 Oct 2022)

  Changed paths:
    M llvm/lib/Target/Sparc/Sparc.td
    M llvm/lib/Target/Sparc/SparcInstr64Bit.td
    M llvm/lib/Target/Sparc/SparcInstrInfo.td

  Log Message:
  -----------
  [Sparc] Fix useDeprecatedPositionallyEncodedOperands errors.

This is a follow-on to https://reviews.llvm.org/D134073.

It renames a few fields to have consistent names, as well as renaming
operands to match the field names.

Behavior is unchanged by this cleanup. (The only generated code change
is for the disassembler for LDSTUB/LDSTUBA, but in both old and new
versions, it fails to add enough operands, and thus triggers a runtime
abort. I will address that bug in a future commit.)

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


  Commit: 26fdad031ca8baa2196a6c8c40c0a23c066e611e
      https://github.com/llvm/llvm-project/commit/26fdad031ca8baa2196a6c8c40c0a23c066e611e
  Author: James Y Knight <jyknight at google.com>
  Date:   2022-10-26 (Wed, 26 Oct 2022)

  Changed paths:
    M llvm/lib/Target/Mips/MicroMips32r6InstrFormats.td
    M llvm/lib/Target/Mips/MicroMips32r6InstrInfo.td
    M llvm/lib/Target/Mips/MicroMipsInstrFormats.td
    M llvm/lib/Target/Mips/Mips.td
    M llvm/lib/Target/Mips/Mips16InstrFormats.td
    M llvm/lib/Target/Mips/Mips16InstrInfo.td
    M llvm/lib/Target/Mips/Mips32r6InstrInfo.td
    M llvm/lib/Target/Mips/MipsEVAInstrFormats.td
    M llvm/lib/Target/Mips/MipsEVAInstrInfo.td
    M llvm/test/MC/Disassembler/Mips/ginv/valid-el.txt
    M llvm/test/MC/Disassembler/Mips/ginv/valid-micromips-el.txt
    M llvm/test/MC/Disassembler/Mips/ginv/valid-micromips.txt
    M llvm/test/MC/Disassembler/Mips/ginv/valid.txt

  Log Message:
  -----------
  [MIPS] Fix useDeprecatedPositionallyEncodedOperands errors.

This is a follow-on to https://reviews.llvm.org/D134073.

The number of MIPS16 changes here is a bit surprising. Many of the
fields with mismatched names were NOT previously choosing the correct
argument positionally, but instead doing something completely wrong
(e.g. it would encode a register where an immediate was expected).

But, machine-code generation for MIPS16 has never actually functioned.
It's also fully untested, thus, the MIPS16 changes, despite changing
behavior, breaks (and fixes) zero tests. This change does not fix
MIPS16 output, but it ought to be at least incrementally less broken.

Outside MIPS16, I believe the only functional change is to the 'ginvi'
instruction: it was previously encoding garbage into a field which was
specified to be '00'. Fortunately, it was covered by tests -- and the
tests were testing the incorrect behavior. So, fixed.

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


Compare: https://github.com/llvm/llvm-project/compare/1bd856fbe5be...26fdad031ca8


More information about the All-commits mailing list