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

[Michael McLoughlin via llvm-dev]

Good question.

The initial motivation was looking at ways of automatically converting
existing (reviewed) implementations of crypto algorithms into Go assembly.
The secondary motivation was learning more about LLVM.

Yes, I considered that approach. Unfortunately the Go disassembler is
incomplete (one example https://golang.org/issue/25617).


On Wed, Oct 3, 2018 at 11:01 AM James Y Knight <jyknight at google.com> wrote:

> 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/955b31c2/attachment.html>