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

[James Y Knight via llvm-dev]

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