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

[Michael McLoughlin via llvm-dev]

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>