summaryrefslogtreecommitdiff
path: root/tools/bugpoint
diff options
context:
space:
mode:
authorPeter Collingbourne <peter@pcc.me.uk>2013-08-05 17:48:04 +0000
committerPeter Collingbourne <peter@pcc.me.uk>2013-08-05 17:48:04 +0000
commitacf4cf775763c6896f14f1d3a988058de05ca704 (patch)
tree5f5dfc289e5bc30745596d0f91146bcb77d6867f /tools/bugpoint
parentaa80e61b0d79ddf9593f6217063574d0c66c3099 (diff)
downloadllvm-acf4cf775763c6896f14f1d3a988058de05ca704.tar.gz
llvm-acf4cf775763c6896f14f1d3a988058de05ca704.tar.bz2
llvm-acf4cf775763c6896f14f1d3a988058de05ca704.tar.xz
Introduce an optimisation for special case lists with large numbers of literal entries.
Our internal regex implementation does not cope with large numbers of anchors very efficiently. Given a ~3600-entry special case list, regex compilation can take on the order of seconds. This patch solves the problem for the special case of patterns matching literal global names (i.e. patterns with no regex metacharacters). Rather than forming regexes from literal global name patterns, add them to a StringSet which is checked before matching against the regex. This reduces regex compilation time by an order of roughly thousands when reading the aforementioned special case list, according to a completely unscientific study. No test cases. I figure that any new tests for this code should check that regex metacharacters are properly recognised. However, I could not find any documentation which documents the fact that the syntax of global names in special case lists is based on regexes. The extent to which regex syntax is supported in special case lists should probably be decided on/documented before writing tests. Differential Revision: http://llvm-reviews.chandlerc.com/D1150 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187732 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'tools/bugpoint')
0 files changed, 0 insertions, 0 deletions