Refactored TableGen backends #8
Conversation
This commit extracts the code which emits generated tables into two printer classes. The Printer is called whenever actual code is written to a file. There is the PrinterLLVM which emits tht code as before and PrinterCapstone which is tailored to or needs (emitting C and generates more info). Additionally missing memory access properties were added to ARMs td files.
|
Hope all auto-sync related PRs can be merged soon~ |
|
@cnSchwarzer Me as well :D Please be aware though, even if the ARM related PRs are merged the auto-sync work is not finalized yet. If you are looking into it for development purposes, please base your work on the PPC branches (capstone-engine/capstone#2013 and https://github.com/Rot127/llvm-capstone/tree/tblgen_capstone_backends_ppc). |
|
Thanks for notice! It seems I just come into this timing that capstone is switching architecture :) Looking forward to this. |
The API for |
|
@Rot127 Plz pr to |
|
@kabeor Done |
|
Great! Merged. |
Adds the refactored TableGen backends used by
auto-sync(capstone-engine/capstone#1949).The refactor basically adds two printer classes. One for LLVM and one for Capstone. Emitter backends then call methods of one of those to emit the code.
For some emitter backends the
PrinterCapstoneclass will generate additional mapping tables.This design is not really sophisticated but works for our use case and is relatively easy to fix in case of conflicts during rebase. But it has some inherent problems when it comes to emitting anything else then the code generated by the emitter backends.
Unfortunately this is a problem from LLVM. See the discussion here (starting at comment from
nhaehnle): https://reviews.llvm.org/D138323Refactoring the emitter backends needs a lot of work and involvement from the LLVM folks, which there seems to be no motivation for currently.