[PATCH] D21091: AArch64: refactor sysreg handling (new TableGen backend!)

[Tim Northover via llvm-commits]

t.p.northover created this revision.
t.p.northover added reviewers: rengolin, jmolloy.
t.p.northover added a subscriber: llvm-commits.
t.p.northover set the repository for this revision to rL LLVM.
Herald added subscribers: mcrosier, rengolin, aemerson.

Hi,

I decided it was time to take a look at improving how we handle the special symbolic AArch64 sysreg names (and those of related instructions). I think the current implementation has a few issues:

  - Large-scale duplication between AArch64BaseInfo.h and AArch64BaseInfo.cpp
  - That weird Mapping class that I have no idea what I was on when I thought it was a good idea.
  - Searches are performed linearly through the entire list.
  - We print absolutely all registers in upper-case, even though some are canonically mixed case (SPSel for example).
  - The ARM ARM specifies sysregs in terms of 5 fields, but those are relegated to comments in our implementation, with a slightly opaque hex value indicating the canonical encoding LLVM will use.

So, with all that in mind I decided to do something about it. This patch adds a new TableGen backend: -gen-searchable-tables, which is quite a bit of code but seems like it ought to be useful elsewhere (though I didn't manage to think of any places immediately). That backend will emit a primary data table (reasonably generic, at the moment it can contain strings, ints and opaque code blobs) together with specified indexes (sorted for a binary search) and lookup functions.

This was actually inspired by trying to make Clang's diagnostics better (specifically warning when a 64-bit register is used for __arm_rsr or __arm_wsr), so any ideas on how best to share it would be welcome (best I've come up with it putting the AArch64-specific file in include/llvm/Target and rebuilding it from Clang).

The other nasty hack is DBGDTRTX_EL0 and DBGDTRRX_EL0 which share an encoding but are written differently in MRS/MSR. I just completely hacked around that in InstPrinter, deciding the extra infrastructure for a generic solution wasn't worth implementing.

So, any suggestions for improvements? Anyone think it's a terrible idea from the start?

Repository:
  rL LLVM

http://reviews.llvm.org/D21091

Files:
  include/llvm/TableGen/SearchableTable.td
  lib/Target/AArch64/AArch64.td
  lib/Target/AArch64/AArch64ISelDAGToDAG.cpp
  lib/Target/AArch64/AArch64InstrFormats.td
  lib/Target/AArch64/AArch64SystemOperands.td
  lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  lib/Target/AArch64/CMakeLists.txt
  lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp
  lib/Target/AArch64/InstPrinter/AArch64InstPrinter.cpp
  lib/Target/AArch64/Utils/AArch64BaseInfo.cpp
  lib/Target/AArch64/Utils/AArch64BaseInfo.h
  test/CodeGen/AArch64/special-reg.ll
  test/MC/AArch64/arm64-spsel-sysreg.s
  test/MC/AArch64/arm64-system-encoding.s
  test/MC/AArch64/basic-a64-instructions.s
  test/MC/Disassembler/AArch64/arm64-system.txt
  test/MC/Disassembler/AArch64/basic-a64-instructions.txt
  utils/TableGen/CMakeLists.txt
  utils/TableGen/SearchableTableEmitter.cpp
  utils/TableGen/TableGen.cpp
  utils/TableGen/TableGenBackends.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D21091.59918.patch
Type: text/x-patch
Size: 192464 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160607/26823751/attachment-0001.bin>