The output of TableGen (intrinsics.gen) seems a bit too clunky
specifically the switching parts (input the string, output the enum).
Moreover, the code makes MSVC barf due to its nesting limit which even
applices to if-else statements.
One one hand, gperf
(Perfect Hash Function Generator) offers a way to
map strings to records without much difficulty (and it does its job
efficiently).
My point is, are there plans to utilize gperf for table generation?
Hi Wilhansen,
The output of TableGen (intrinsics.gen) seems a bit too clunky
specifically the switching parts (input the string, output the enum).
Moreover, the code makes MSVC barf due to its nesting limit which even
applices to if-else statements.
Does introducing gotos into the generated code help as a temporary
workaround for MSVC?
Cheers,
Ralph.
I believe that some of this will be alleviated by switching to a Trie data structure, though Anton would know for sure.
The output of TableGen (intrinsics.gen) seems a bit too clunky
specifically the switching parts (input the string, output the enum).
Moreover, the code makes MSVC barf due to its nesting limit which even
applices to if-else statements.
Right, fixing the VC++ issue is straight-forward. I will do it in the next couple of days if noone beats me to it.
One one hand, gperf
(Perfect Hash Function Generator) offers a way to
map strings to records without much difficulty (and it does its job
efficiently).My point is, are there plans to utilize gperf for table generation?
Not that I know of. Anton is working on a better and more aggressive implementation of this code in question though,
-Chris
The output of TableGen (intrinsics.gen) seems a bit too clunky
specifically the switching parts (input the string, output the enum).
Moreover, the code makes MSVC barf due to its nesting limit which even
applices to if-else statements.One one hand, gperf
(Perfect Hash Function Generator) offers a way to
map strings to records without much difficulty (and it does its job
efficiently).My point is, are there plans to utilize gperf for table generation?
There isn't any plan to do so. I agree the output of TableGen can be much improved. But this hasn't been a high priority issue. If you have an interest in improving this, please do! But I would prefer the improvement be made in TableGen that would not require another external tool.
Thanks!
Evan
This should be fixed now, please verify, thanks!
-Chris
FYI, gperf is a very good perfect hash utility written originally by Doug Schmidt (of ACE fame). I used it in XPS for speeding up XML parsing by hashing all the element and attribute names. Unfortunately, its a code generator, which we're trying to get rid of in LLVM. Still, I recommend the tool highly.
Reid.
The newer code that TableGen produces is indeed lower however, MSVC
still throws the same error messages (and moreover, I don't think
they're fixing it anytime soon.. I'll try to re-open this issue to
them). Also, it seems that the new code produces an extraneous "if
(0);" statement before each of the else-if chains. Normally, compilers
would (and should) just optimize them away but it still counts agains
MSVC's ``nesting limit''.
I'm a bit familiar with the algorithm behind gperf (though I still
have to actually study the source code since they added something
after publishing the paper about gperf). So, is it possible to
reimplement that algorithm in the TableGen of LLVM? That would
eliminate the dependency to gperf however, since gperf is GPLv2'ed,
will the licenses be compatible? AFAIK, yes.
OT: Sorry for my multiple sends to the mailing list, been wrestling
with GMail having two mail accounts.