[PATCH] D14257: [AsmParser] Generalize matching for grammars without mnemonic-lead statements.

[Colin LeMahieu via llvm-commits]

colinl added a comment.

The cost is higher than simply matching though it could be improved from where it is right now.  One of the things we're focusing on is making sure the codebase is in sync with the community.  We want to work on performance improvements though if we're not in sync our efforts will be wasted.

>From what I can see the closest idea we have to improving the parsing performance without a major rework is to figure out how to get tablegen to pick a mnemonic in a target dependent way instead of simply the first operand in the instruction.  Right now tablegen doesn't link with any target code; I don't see a path to do this cleanly.

Having the Hexagon asm parser be slow in some cases isn't desirable though I think it's less desirable to have no parser at all.  I ran a benchmark against a more real world module instead of the worst case synthetic module, with a 450mb assembly file at ~11million lines it took 96 seconds; maybe it can be improved but the degenerate case seems to not be the usual case.

It would be nice if there was at least one other target that needed this type of change to justify more of a target independent revamp but as it stands it would be a large amount of rework to fix what is mostly an edge case on one target.  We want to make sure none of the hexagon stuff will negatively impact the target independent code and from what I see with the change you put in to remove the mnemonic entry from the match table, the target independent impact has been address.

Do we think there are outstanding issues that justify following through on reverting?
Do we think the suboptimal performance of hexagon asm parsing on synthetic tests justifies a larger target independent rework prior to accepting the parser?

In my view I see the hexagon asm parsing performance as adequate for the moment.


Repository:
  rL LLVM

http://reviews.llvm.org/D14257