[LLVMdev] Hexagon Assembly parser question

[David Young]

Hi Jim,

Thanks for the quick feedback!

 

I have 2 thoughts along the direction that you suggest.

 

Currently the parser seems to be sorting/searching the instruction table by
Mnemonic as the first pass.  Is it possible to sort by ConvertFn, and add a
generic mnemonic field to this?  Then we could convert the assembly parser
to search first for the format of the instruction (after first parsing out
the formatting fields), and then see if the format is supported by the
mnemonic.

 

Just for my own reference, the Table elements are defined:

 

static const char *const MnemonicTable;

    uint32_t Mnemonic;

    uint16_t Opcode;

    uint16_t ConvertFn;

    uint32_t RequiredFeatures;

    uint16_t Classes[18];

 

This may benefit the matching generally by evening out the what the
std::equal_range function must search through, and may make my task easier
since there is no clearly defined mnemonics in much of Hexagon assembly
grammar.

 

The other thought  is whether or not we night be able to use stl::map
(ordered tree) or std::tr1::unordered_map for a hash implementation when
doing the matching.  It seems that most of the hard work of turning the
format into a ConvertFn index has already been done by the current
implementation.   Maybe a few Hashes can get you to a match directly?

 

Sorry for any dumb questions.  I'm a LLVM newbie.

 

Regards,

David

 

 

 

 

 

From: Jim Grosbach [mailto:grosbach at apple.com] 
Sent: Wednesday, October 17, 2012 6:55 PM
To: David Young
Cc: 'LLVM Developers Mailing List'
Subject: Re: [LLVMdev] Hexagon Assembly parser question

 

 

On Oct 17, 2012, at 3:29 PM, David Young <davidy at codeaurora.org> wrote:





Hi,

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. 

 

But..

Hexagon assembly does not follow the "Mnemonic Rx Rx ." format that is
expected by the assembly parsing infrastructure, represented by:

StringRef Mnemonic = ((ARMOperand*)Operands[0])->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.

 

-Jim





 

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.

 

Regards,

David

_______________________________________________
LLVM Developers mailing list
 <mailto:LLVMdev at cs.uiuc.edu> LLVMdev at cs.uiuc.edu
<http://llvm.cs.uiuc.edu> http://llvm.cs.uiuc.edu
 <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121017/1ea10aaa/attachment.html>