<div dir="ltr">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.<div><br></div><div>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.<div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 3, 2018 at 1:14 PM Michael McLoughlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello,<div><br></div><div>I am interested in experimenting with Golang assembly with LLVM on X86. Golang Assembly is most similar to AT&T/GAS with some differences:</div><div><br></div><div>* A small number of instructions have operand order flipped</div><div>* Some mnemonics are different</div><div>* Different register naming conventions</div><div><br></div><div>Iskander Sharipov covers details here: <a href="https://quasilyte.github.io/blog/post/go-asm-complementary-reference/" target="_blank">https://quasilyte.github.io/blog/post/go-asm-complementary-reference/</a></div><div><br></div><div>I have started looking into how the `X86AsmPrinter` and `InstPrinter` works. It seems like there could be two high-level approaches:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Mike</div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>