[llvm-dev] Advice on adding Golang (Plan 9) x86 assembly variant (original) (raw)

James Y Knight via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 3 11:00:48 PDT 2018

I'd start by asking why you want to do this? Is there some more concrete goal you had in mind, that you want this for? It doesn't really seem worthwhile to me.

If you just want to create Go assembly from LLVM input, I would suggest having LLVM emit a .o file and then run "go tool objdump foo.o" to disassemble it using Go's disassembler.

On Wed, Oct 3, 2018 at 1:14 PM Michael McLoughlin via llvm-dev < llvm-dev at lists.llvm.org> wrote:

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|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

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181003/d3860f5c/attachment.html>

More information about the llvm-dev mailing list