llvm dev - Oct 2018 - 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/20181002/95769ec7/attachment.html>

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>