[LLVMdev] Hexagon Assembly parser question
grosbach at apple.com
Wed Oct 17 16:55:02 PDT 2012
On Oct 17, 2012, at 3:29 PM, David Young <davidy at codeaurora.org> wrote:
> I’m trying to enable the hexagon LLVM assembly parser. It seem like there is a lot of work that has been done to make this parsing straightforward.
> Hexagon assembly does not follow the “Mnemonic Rx Rx …” format that is expected by the assembly parsing infrastructure, represented by:
> StringRef Mnemonic = ((ARMOperand*)Operands)->getToken();
> This Mnemonic location assumption applies to both the Tablegen Backend AsmMatcherEmitter processing, and the .inc file it produces where MatchInstructionImpl is the entry point by which the assembly input is parsed.
> However Hexagon assembly has some features that make it more readable, such as r1 = r2, or if(r1) r2 = mem(#immediate). This makes taking advantage of the existing LLVM code difficult.
> Currently, I see two options.
> One is to preformat the assembly string(s) obtained from the td files so that it is matches the format that the tablegen backend expects, and also preformat the assembly input so that it can be matched against the preformatted assembly strings.
I agree this sounds pretty hacky.
> The other is to write a whole new TD backend that doesn’t rely on the Mnemonic location assumption. And hope someday to merge this backend with the current AsmMatcherEmitter.
The table is sorted by mnemonic (more abstractly, by operator). That's pretty fundamental to how it works, so sticking with that would be good unless you want to write an entirely new algorithm. You could probably stick with the current basic stuff with some fiddling in tablegen where the asm string gets split apart when building up matchables to re-order things appropriately. Then your ParseInstruction() implementation would do similar tricks. The printer should "just work," thankfully.
That said, you'll also likely have to do a bit of work in the generic AsmParser code, as it'll likely look at statements like these and not realize they're instruction sequences. The "mnemonic <whitespace> operands" format is pretty strongly imprinted on everything. That's not completely unfixable, of course, but it may be a bit tricky to avoid syntactic ambiguities. Not impossible, mind, just tricky and something to pay very close attention to in your design.
> I am leaning toward the latter. The other seems like it will create many more problems in the long run. Any thoughts, comments, or recommended directions are appreciated.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev