Michael McLoughlin via llvm-dev
2018-Oct-03 15:48 UTC
[llvm-dev] Advice on adding Golang (Plan 9) x86 assembly variant
Hello, I am interested in experimenting with Golang assembly with LLVM on X86. Golang Assembly is most similar to AT&T/GAS with some differences: * A small number of instructions have operand order flipped * Some mnemonics are different * Different register naming conventions Iskander Sharipov covers details here: https://quasilyte.github.io/blog/post/go-asm-complementary-reference/ I have started looking into how the `X86AsmPrinter` and `InstPrinter` works. It seems like there could be two high-level approaches: 1. Treat Golang assembly as a completely separate third variant. This would require substantial edits to various X86Instr*.td files, mainly to account for variant number 2 in all the AsmString entries. That is, strings like "mov{l}\t{$src, $dst|$dst, $src}" would need to account for a third possibility. Likely much of this could be automated, but the changes would be substantial. Then hopefully other differences could be handled with MnemonicAlias. Further changes would be required to `X86AsmPrinter.cc`, parsers, and no doubt many other places I haven't even seen yet. 2. I am interested in whether it's feasible (and easier) to treat Golang as a "sub-variant" of AT&T. That is, no changes made to the *.td files, but the differences between AT&T and Golang assembly are handled later in code (X86AsmPrinter and the like). I have not fully thought this through yet. I thought I would reach out for some advice from people who might have a better intuition. Are either of these approaches reasonable? Is there a better third way? Is the whole thing going to be prohibitively difficult? Any pointers appreciated. Cheers, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181003/a9c1cf1b/attachment.html>