When used to find an exact match, some extra context can be used to
totally cut some computations.
This saves 1% of the instruction count when pre processing sqlite3.c
through
valgrind --tool=callgrind ./bin/clang -E sqlite3.c -o/dev/null
Differential D142026
Optimize OptTable::findNearest implementation and usage serge-sans-paille on Jan 18 2023, 8:14 AM. Authored by
Details When used to find an exact match, some extra context can be used to This saves 1% of the instruction count when pre processing sqlite3.c valgrind --tool=callgrind ./bin/clang -E sqlite3.c -o/dev/null
Diff Detail
Unit Tests Event TimelineComment Actions FYI I just noticed some i686 failures that look something like this: /builddir/build/BUILD/llvm-16.0.0.src/redhat-linux-build/unittests/Option/./OptionTests --gtest_filter=OptTableTest/0.FindNearest -- /builddir/build/BUILD/llvm-16.0.0.src/unittests/Option/OptionParsingTest.cpp:314: Failure Expected equality of these values: 1U Which is: 1 T.findNearest("-blorb", Nearest) Which is: 4294967295 /builddir/build/BUILD/llvm-16.0.0.src/unittests/Option/OptionParsingTest.cpp:315: Failure Expected equality of these values: Nearest Which is: "" "-blorp" Plausibly caused by this change -- I'm thinking that MaximumDistance is initialized to UINT_MAX - 1, but then we cast that to a signed integer and compare that, so it wraps to a large negative number. Comment Actions
@nikic : I thought I fixed that with e8a163dc03e6913360beb305620104ba129c081c ... is it included in your build? |
I think this changes MinimumLength from the default of 4 to 0?