1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 20:23:11 +01:00
llvm-mirror/tools/llvm-yaml-numeric-parser-fuzzer/yaml-numeric-parser-fuzzer.cpp

46 lines
1.3 KiB
C++
Raw Normal View History

//===-- yaml-numeric-parser-fuzzer.cpp - Fuzzer for YAML numeric parser ---===//
[llvm] Make YAML serialization up to 2.5 times faster This patch significantly improves performance of the YAML serializer by optimizing `YAML::isNumeric` function. This function is called on the most strings and is highly inefficient for two reasons: * It uses `Regex`, which is parsed and compiled each time this function is called * It uses multiple passes which are not necessary This patch introduces stateful ad hoc YAML number parser which does not rely on `Regex`. It also fixes YAML number format inconsistency: current implementation supports C-stile octal number format (`01234567`) which was present in YAML 1.0 specialization (http://yaml.org/spec/1.0/), [Section 2.4. Tags, Example 2.19] but was deprecated and is no longer present in latest YAML 1.2 specification (http://yaml.org/spec/1.2/spec.html), see [Section 10.3.2. Tag Resolution]. Since the rest of the rest of the implementation does not support other deprecated YAML 1.0 numeric features such as sexagecimal numbers, commas as delimiters it is treated as inconsistency and not longer supported. This patch also adds unit tests to ensure the validity of proposed implementation. This performance bottleneck was identified while profiling Clangd's global-symbol-builder tool with my colleague @ilya-biryukov. The substantial part of the runtime was spent during a single-thread Reduce phase, which concludes with YAML serialization of collected symbol collection. Regex matching was accountable for approximately 45% of the whole runtime (which involves sharded Map phase), now it is reduced to 18% (which is spent in `clang::clangd::CanonicalIncludes` and can be also optimized because all used regexes are in fact either suffix matches or exact matches). `llvm-yaml-numeric-parser-fuzzer` was used to ensure the validity of the proposed regex replacement. Fuzzing for ~60 hours using 10 threads did not expose any bugs. Benchmarking `global-symbol-builder` (using `hyperfine --warmup 2 --min-runs 5 'command 1' 'command 2'`) tool by processing a reasonable amount of code (26 source files matched by `clang-tools-extra/clangd/*.cpp` with all transitive includes) confirmed our understanding of the performance bottleneck nature as it speeds up the command by the factor of 1.6x: | Command | Mean [s] | Min…Max [s] | | this patch (D50839) | 84.7 ± 0.6 | 83.3…84.7 | | master (rL339849) | 133.1 ± 0.8 | 132.4…134.6 | Using smaller samples (e.g. by collecting symbols from `clang-tools-extra/clangd/AST.cpp` only) yields even better performance improvement, which is expected because Map phase takes less time compared to Reduce and is 2.05x faster and therefore would significantly improve the performance of standalone YAML serializations. | Command | Mean [ms] | Min…Max [ms] | | this patch (D50839) | 3702.2 ± 48.7 | 3635.1…3752.3 | | master (rL339849) | 7607.6 ± 109.5 | 7533.3…7796.4 | Reviewed by: zturner, ilya-biryukov Differential revision: https://reviews.llvm.org/D50839 llvm-svn: 340154
2018-08-20 09:00:36 +02: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
[llvm] Make YAML serialization up to 2.5 times faster This patch significantly improves performance of the YAML serializer by optimizing `YAML::isNumeric` function. This function is called on the most strings and is highly inefficient for two reasons: * It uses `Regex`, which is parsed and compiled each time this function is called * It uses multiple passes which are not necessary This patch introduces stateful ad hoc YAML number parser which does not rely on `Regex`. It also fixes YAML number format inconsistency: current implementation supports C-stile octal number format (`01234567`) which was present in YAML 1.0 specialization (http://yaml.org/spec/1.0/), [Section 2.4. Tags, Example 2.19] but was deprecated and is no longer present in latest YAML 1.2 specification (http://yaml.org/spec/1.2/spec.html), see [Section 10.3.2. Tag Resolution]. Since the rest of the rest of the implementation does not support other deprecated YAML 1.0 numeric features such as sexagecimal numbers, commas as delimiters it is treated as inconsistency and not longer supported. This patch also adds unit tests to ensure the validity of proposed implementation. This performance bottleneck was identified while profiling Clangd's global-symbol-builder tool with my colleague @ilya-biryukov. The substantial part of the runtime was spent during a single-thread Reduce phase, which concludes with YAML serialization of collected symbol collection. Regex matching was accountable for approximately 45% of the whole runtime (which involves sharded Map phase), now it is reduced to 18% (which is spent in `clang::clangd::CanonicalIncludes` and can be also optimized because all used regexes are in fact either suffix matches or exact matches). `llvm-yaml-numeric-parser-fuzzer` was used to ensure the validity of the proposed regex replacement. Fuzzing for ~60 hours using 10 threads did not expose any bugs. Benchmarking `global-symbol-builder` (using `hyperfine --warmup 2 --min-runs 5 'command 1' 'command 2'`) tool by processing a reasonable amount of code (26 source files matched by `clang-tools-extra/clangd/*.cpp` with all transitive includes) confirmed our understanding of the performance bottleneck nature as it speeds up the command by the factor of 1.6x: | Command | Mean [s] | Min…Max [s] | | this patch (D50839) | 84.7 ± 0.6 | 83.3…84.7 | | master (rL339849) | 133.1 ± 0.8 | 132.4…134.6 | Using smaller samples (e.g. by collecting symbols from `clang-tools-extra/clangd/AST.cpp` only) yields even better performance improvement, which is expected because Map phase takes less time compared to Reduce and is 2.05x faster and therefore would significantly improve the performance of standalone YAML serializations. | Command | Mean [ms] | Min…Max [ms] | | this patch (D50839) | 3702.2 ± 48.7 | 3635.1…3752.3 | | master (rL339849) | 7607.6 ± 109.5 | 7533.3…7796.4 | Reviewed by: zturner, ilya-biryukov Differential revision: https://reviews.llvm.org/D50839 llvm-svn: 340154
2018-08-20 09:00:36 +02:00
//
//===----------------------------------------------------------------------===//
#include "llvm/ADT/StringRef.h"
#include "llvm/Support/Regex.h"
#include "llvm/Support/YAMLTraits.h"
#include <string>
inline bool isNumericRegex(llvm::StringRef S) {
static llvm::Regex Infinity("^[-+]?(\\.inf|\\.Inf|\\.INF)$");
static llvm::Regex Base8("^0o[0-7]+$");
static llvm::Regex Base16("^0x[0-9a-fA-F]+$");
static llvm::Regex Float(
"^[-+]?(\\.[0-9]+|[0-9]+(\\.[0-9]*)?)([eE][-+]?[0-9]+)?$");
[llvm] Make YAML serialization up to 2.5 times faster This patch significantly improves performance of the YAML serializer by optimizing `YAML::isNumeric` function. This function is called on the most strings and is highly inefficient for two reasons: * It uses `Regex`, which is parsed and compiled each time this function is called * It uses multiple passes which are not necessary This patch introduces stateful ad hoc YAML number parser which does not rely on `Regex`. It also fixes YAML number format inconsistency: current implementation supports C-stile octal number format (`01234567`) which was present in YAML 1.0 specialization (http://yaml.org/spec/1.0/), [Section 2.4. Tags, Example 2.19] but was deprecated and is no longer present in latest YAML 1.2 specification (http://yaml.org/spec/1.2/spec.html), see [Section 10.3.2. Tag Resolution]. Since the rest of the rest of the implementation does not support other deprecated YAML 1.0 numeric features such as sexagecimal numbers, commas as delimiters it is treated as inconsistency and not longer supported. This patch also adds unit tests to ensure the validity of proposed implementation. This performance bottleneck was identified while profiling Clangd's global-symbol-builder tool with my colleague @ilya-biryukov. The substantial part of the runtime was spent during a single-thread Reduce phase, which concludes with YAML serialization of collected symbol collection. Regex matching was accountable for approximately 45% of the whole runtime (which involves sharded Map phase), now it is reduced to 18% (which is spent in `clang::clangd::CanonicalIncludes` and can be also optimized because all used regexes are in fact either suffix matches or exact matches). `llvm-yaml-numeric-parser-fuzzer` was used to ensure the validity of the proposed regex replacement. Fuzzing for ~60 hours using 10 threads did not expose any bugs. Benchmarking `global-symbol-builder` (using `hyperfine --warmup 2 --min-runs 5 'command 1' 'command 2'`) tool by processing a reasonable amount of code (26 source files matched by `clang-tools-extra/clangd/*.cpp` with all transitive includes) confirmed our understanding of the performance bottleneck nature as it speeds up the command by the factor of 1.6x: | Command | Mean [s] | Min…Max [s] | | this patch (D50839) | 84.7 ± 0.6 | 83.3…84.7 | | master (rL339849) | 133.1 ± 0.8 | 132.4…134.6 | Using smaller samples (e.g. by collecting symbols from `clang-tools-extra/clangd/AST.cpp` only) yields even better performance improvement, which is expected because Map phase takes less time compared to Reduce and is 2.05x faster and therefore would significantly improve the performance of standalone YAML serializations. | Command | Mean [ms] | Min…Max [ms] | | this patch (D50839) | 3702.2 ± 48.7 | 3635.1…3752.3 | | master (rL339849) | 7607.6 ± 109.5 | 7533.3…7796.4 | Reviewed by: zturner, ilya-biryukov Differential revision: https://reviews.llvm.org/D50839 llvm-svn: 340154
2018-08-20 09:00:36 +02:00
if (S.equals(".nan") || S.equals(".NaN") || S.equals(".NAN"))
return true;
if (Infinity.match(S))
return true;
if (Base8.match(S))
return true;
if (Base16.match(S))
return true;
if (Float.match(S))
return true;
return false;
}
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
std::string Input(reinterpret_cast<const char *>(Data), Size);
llvm::erase_value(Input, 0);
[llvm] Make YAML serialization up to 2.5 times faster This patch significantly improves performance of the YAML serializer by optimizing `YAML::isNumeric` function. This function is called on the most strings and is highly inefficient for two reasons: * It uses `Regex`, which is parsed and compiled each time this function is called * It uses multiple passes which are not necessary This patch introduces stateful ad hoc YAML number parser which does not rely on `Regex`. It also fixes YAML number format inconsistency: current implementation supports C-stile octal number format (`01234567`) which was present in YAML 1.0 specialization (http://yaml.org/spec/1.0/), [Section 2.4. Tags, Example 2.19] but was deprecated and is no longer present in latest YAML 1.2 specification (http://yaml.org/spec/1.2/spec.html), see [Section 10.3.2. Tag Resolution]. Since the rest of the rest of the implementation does not support other deprecated YAML 1.0 numeric features such as sexagecimal numbers, commas as delimiters it is treated as inconsistency and not longer supported. This patch also adds unit tests to ensure the validity of proposed implementation. This performance bottleneck was identified while profiling Clangd's global-symbol-builder tool with my colleague @ilya-biryukov. The substantial part of the runtime was spent during a single-thread Reduce phase, which concludes with YAML serialization of collected symbol collection. Regex matching was accountable for approximately 45% of the whole runtime (which involves sharded Map phase), now it is reduced to 18% (which is spent in `clang::clangd::CanonicalIncludes` and can be also optimized because all used regexes are in fact either suffix matches or exact matches). `llvm-yaml-numeric-parser-fuzzer` was used to ensure the validity of the proposed regex replacement. Fuzzing for ~60 hours using 10 threads did not expose any bugs. Benchmarking `global-symbol-builder` (using `hyperfine --warmup 2 --min-runs 5 'command 1' 'command 2'`) tool by processing a reasonable amount of code (26 source files matched by `clang-tools-extra/clangd/*.cpp` with all transitive includes) confirmed our understanding of the performance bottleneck nature as it speeds up the command by the factor of 1.6x: | Command | Mean [s] | Min…Max [s] | | this patch (D50839) | 84.7 ± 0.6 | 83.3…84.7 | | master (rL339849) | 133.1 ± 0.8 | 132.4…134.6 | Using smaller samples (e.g. by collecting symbols from `clang-tools-extra/clangd/AST.cpp` only) yields even better performance improvement, which is expected because Map phase takes less time compared to Reduce and is 2.05x faster and therefore would significantly improve the performance of standalone YAML serializations. | Command | Mean [ms] | Min…Max [ms] | | this patch (D50839) | 3702.2 ± 48.7 | 3635.1…3752.3 | | master (rL339849) | 7607.6 ± 109.5 | 7533.3…7796.4 | Reviewed by: zturner, ilya-biryukov Differential revision: https://reviews.llvm.org/D50839 llvm-svn: 340154
2018-08-20 09:00:36 +02:00
if (!Input.empty() && llvm::yaml::isNumeric(Input) != isNumericRegex(Input))
LLVM_BUILTIN_TRAP;
[llvm] Make YAML serialization up to 2.5 times faster This patch significantly improves performance of the YAML serializer by optimizing `YAML::isNumeric` function. This function is called on the most strings and is highly inefficient for two reasons: * It uses `Regex`, which is parsed and compiled each time this function is called * It uses multiple passes which are not necessary This patch introduces stateful ad hoc YAML number parser which does not rely on `Regex`. It also fixes YAML number format inconsistency: current implementation supports C-stile octal number format (`01234567`) which was present in YAML 1.0 specialization (http://yaml.org/spec/1.0/), [Section 2.4. Tags, Example 2.19] but was deprecated and is no longer present in latest YAML 1.2 specification (http://yaml.org/spec/1.2/spec.html), see [Section 10.3.2. Tag Resolution]. Since the rest of the rest of the implementation does not support other deprecated YAML 1.0 numeric features such as sexagecimal numbers, commas as delimiters it is treated as inconsistency and not longer supported. This patch also adds unit tests to ensure the validity of proposed implementation. This performance bottleneck was identified while profiling Clangd's global-symbol-builder tool with my colleague @ilya-biryukov. The substantial part of the runtime was spent during a single-thread Reduce phase, which concludes with YAML serialization of collected symbol collection. Regex matching was accountable for approximately 45% of the whole runtime (which involves sharded Map phase), now it is reduced to 18% (which is spent in `clang::clangd::CanonicalIncludes` and can be also optimized because all used regexes are in fact either suffix matches or exact matches). `llvm-yaml-numeric-parser-fuzzer` was used to ensure the validity of the proposed regex replacement. Fuzzing for ~60 hours using 10 threads did not expose any bugs. Benchmarking `global-symbol-builder` (using `hyperfine --warmup 2 --min-runs 5 'command 1' 'command 2'`) tool by processing a reasonable amount of code (26 source files matched by `clang-tools-extra/clangd/*.cpp` with all transitive includes) confirmed our understanding of the performance bottleneck nature as it speeds up the command by the factor of 1.6x: | Command | Mean [s] | Min…Max [s] | | this patch (D50839) | 84.7 ± 0.6 | 83.3…84.7 | | master (rL339849) | 133.1 ± 0.8 | 132.4…134.6 | Using smaller samples (e.g. by collecting symbols from `clang-tools-extra/clangd/AST.cpp` only) yields even better performance improvement, which is expected because Map phase takes less time compared to Reduce and is 2.05x faster and therefore would significantly improve the performance of standalone YAML serializations. | Command | Mean [ms] | Min…Max [ms] | | this patch (D50839) | 3702.2 ± 48.7 | 3635.1…3752.3 | | master (rL339849) | 7607.6 ± 109.5 | 7533.3…7796.4 | Reviewed by: zturner, ilya-biryukov Differential revision: https://reviews.llvm.org/D50839 llvm-svn: 340154
2018-08-20 09:00:36 +02:00
return 0;
}