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

[Craig Topper via llvm-commits]

Any idea why Hexagon was so much slower than x86 even when it using a
binary search for "wait(r0)"?

On Mon, Jan 11, 2016 at 11:30 AM, Colin LeMahieu <colinl at codeaurora.org>
wrote:

> colinl added a comment.
>
> Hah, you're right, good catch.  I changed the test to "r0=mpy(r0.l,
> r0.l):<<1:sat" and it definitely went sub-optimal.
>
> > colinl at COLINL1 ~/llvm-master.ninja
>
> >  $ time ./bin/llvm-mc.exe -triple=hexagon-unknown-elf -filetype=obj
> huge.s -o huge.o
>
> >
>
> > real    8m8.593s
>
> >  user    0m0.000s
>
> >  sys     0m0.031s
>
>
>
>
> > colinl at COLINL1 ~/BRANCH_7_2.ninja
>
> >  $ time ./bin/llvm-mc.exe -triple=hexagon-unknown-elf -filetype=obj
> huge.s -o huge.o
>
> >
>
> > real    0m32.186s
>
> >  user    0m0.015s
>
> >  sys     0m0.015s
>
>
> I think the easier part of getting the mnemonic searching technique
> working is in AsmParser where we're presented with the actual operands and
> could search through them with a target-specific hook and present the
> parser with a mnemonic in a canonical way.
>
> I think the harder part is getting tablegen to produce a match table that
> comes up with the same mnemonic given what's parsed from the .td files.  In
> our internal version we placed this code directly in the TI code in
> tablegen because we were only enabling the hexagon target; this would
> obviously be unacceptable.  It seems like tablegen in AsmMatcherEmitter.cpp
> would need to a way to execute target specific code on each parsed
> instruction text to retrieve what the mnemonic should be.
>
> I'm not aware of a place where TableGen does this type of thing already to
> use as a reference, any ideas?
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D14257
>
>
>
>


-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160111/bd9831ee/attachment.html>