Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 10:54:54 +08:00
|
|
|
//===-- TrigramIndex.cpp - a heuristic for SpecialCaseList ----------------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 10:54:54 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// TrigramIndex implements a heuristic for SpecialCaseList that allows to
|
|
|
|
// filter out ~99% incoming queries when all regular expressions in the
|
|
|
|
// SpecialCaseList are simple wildcards with '*' and '.'. If rules are more
|
|
|
|
// complicated, the check is defeated and it will always pass the queries to a
|
|
|
|
// full regex.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Support/TrigramIndex.h"
|
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2020-04-12 21:30:52 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 10:54:54 +08:00
|
|
|
|
|
|
|
#include <set>
|
|
|
|
#include <string>
|
2017-06-06 19:49:48 +08:00
|
|
|
#include <unordered_map>
|
Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 10:54:54 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
static const char RegexAdvancedMetachars[] = "()^$|+?[]\\{}";
|
|
|
|
|
2016-12-03 07:30:16 +08:00
|
|
|
static bool isAdvancedMetachar(unsigned Char) {
|
|
|
|
return strchr(RegexAdvancedMetachars, Char) != nullptr;
|
Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 10:54:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void TrigramIndex::insert(std::string Regex) {
|
|
|
|
if (Defeated) return;
|
|
|
|
std::set<unsigned> Was;
|
|
|
|
unsigned Cnt = 0;
|
|
|
|
unsigned Tri = 0;
|
|
|
|
unsigned Len = 0;
|
2016-12-03 07:30:16 +08:00
|
|
|
bool Escaped = false;
|
Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 10:54:54 +08:00
|
|
|
for (unsigned Char : Regex) {
|
2016-12-03 07:30:16 +08:00
|
|
|
if (!Escaped) {
|
|
|
|
// Regular expressions allow escaping symbols by preceding it with '\'.
|
|
|
|
if (Char == '\\') {
|
|
|
|
Escaped = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (isAdvancedMetachar(Char)) {
|
|
|
|
// This is a more complicated regex than we can handle here.
|
|
|
|
Defeated = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (Char == '.' || Char == '*') {
|
|
|
|
Tri = 0;
|
|
|
|
Len = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (Escaped && Char >= '1' && Char <= '9') {
|
|
|
|
Defeated = true;
|
|
|
|
return;
|
Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 10:54:54 +08:00
|
|
|
}
|
2016-12-03 07:30:16 +08:00
|
|
|
// We have already handled escaping and can reset the flag.
|
|
|
|
Escaped = false;
|
Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 10:54:54 +08:00
|
|
|
Tri = ((Tri << 8) + Char) & 0xFFFFFF;
|
|
|
|
Len++;
|
|
|
|
if (Len < 3)
|
|
|
|
continue;
|
|
|
|
// We don't want the index to grow too much for the popular trigrams,
|
|
|
|
// as they are weak signals. It's ok to still require them for the
|
|
|
|
// rules we have already processed. It's just a small additional
|
|
|
|
// computational cost.
|
|
|
|
if (Index[Tri].size() >= 4)
|
|
|
|
continue;
|
|
|
|
Cnt++;
|
|
|
|
if (!Was.count(Tri)) {
|
|
|
|
// Adding the current rule to the index.
|
|
|
|
Index[Tri].push_back(Counts.size());
|
|
|
|
Was.insert(Tri);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!Cnt) {
|
|
|
|
// This rule does not have remarkable trigrams to rely on.
|
|
|
|
// We have to always call the full regex chain.
|
|
|
|
Defeated = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
Counts.push_back(Cnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool TrigramIndex::isDefinitelyOut(StringRef Query) const {
|
|
|
|
if (Defeated)
|
|
|
|
return false;
|
|
|
|
std::vector<unsigned> CurCounts(Counts.size());
|
|
|
|
unsigned Tri = 0;
|
|
|
|
for (size_t I = 0; I < Query.size(); I++) {
|
|
|
|
Tri = ((Tri << 8) + Query[I]) & 0xFFFFFF;
|
|
|
|
if (I < 2)
|
|
|
|
continue;
|
|
|
|
const auto &II = Index.find(Tri);
|
|
|
|
if (II == Index.end())
|
|
|
|
continue;
|
|
|
|
for (size_t J : II->second) {
|
|
|
|
CurCounts[J]++;
|
|
|
|
// If we have reached a desired limit, we have to look at the query
|
|
|
|
// more closely by running a full regex.
|
|
|
|
if (CurCounts[J] >= Counts[J])
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|