Fixed out of bounds read in AVX512VBMI version of fdr_exec_fat_teddy (#322)
* Replaced the 32 byte read with a properly truncated mapped read
* Added a unit test
Co-authored-by: Rafał Dowgird <rafal.dowgird@rtbhouse.com>
An old commit (24ae1670d) had the side effect of moving cmake defines after
they were being used. This patch move them back to be defined before being used.
Speed hsbench back up by ~ 0.8%
Signed-off-by: Yoan Picchi <yoan.picchi@arm.com>
Revert the code that produced the regression error in #317
Add the regression error to a unit test regressions.cpp along with the rebar tests
---------
Co-authored-by: gtsoul-tech <gtsoulkanakis@gmail.com>
* Revert "Fix noodle SVE2 off by one bug"
This patch was fixing the bug when it happens at the end of the buffer
but it wasn't fixing it when we do scanDoubleOnce before the main loop
The next patch fix this bug for both case instead
This reverts commit 48dd0e5ff0bc1995d62461c92cfb76d44d1d0105.
* Fix noodle spurious match with \0 chars for SVE2
When sve2's noodle process a non full vector (before the main loop or
at the end of it), a fake \0 was being parsed, trigerring a match for
pattern that ended with \0. This patch fix this.
Signed-off-by: Yoan Picchi <yoan.picchi@arm.com>
---------
Signed-off-by: Yoan Picchi <yoan.picchi@arm.com>
Vectorscan requires SSE4.2 as a minimum on x86_64. For Hyperscan this
used to be SSSE3.
Applications that use the library call hs_valid_platform() to check if
the CPU fulfils this minimum requirement. However, when Vectorscan
upgraded to SSE4.2, the check was not updated. This leads to the library
trying to execute instructions that are not supported, resulting in the
application to crash.
This might not have been noticed as the CPUs that do not support SSE4.2
are rather old and unlikely to run any load where performance is an
issue. However, I believe that the library should not let the
application crash.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Vectorscan used to reject such pattern because they were being compared
to "" and found to be an empty string. We now check the pattern length
instead.
Signed-off-by: Yoan Picchi <yoan.picchi@arm.com>
By using svmatch on 16 bit lanes with a 8 bit predicate, we end up
including an undefined character in the pattern checks. The inactive
lane after load contains an undefined value, usually \0. Patterns
using \0 as the last character would then match this spurious
character, returning a match beyond the buffer's end. The fix checks
for such matches and rejects them.
Signed-off-by: Yoan Picchi <yoan.picchi@arm.com>
* maybe fix the hsbench issue (check_ssse3 again) in sse2/simde env
* fix the last failing unit test with fat
---------
Co-authored-by: G.E. <gregory.economou@vectorcamp.gr>
This allows the use of SIMDE library to emulate SSSE3/SSE4.2 instructions on SSE2-only (x86-64-v2) hardware.
---------
Co-authored-by: G.E <gregory.economou@vectorcamp.gr>
Co-authored-by: Konstantinos Margaritis <konstantinos@vectorcamp.gr>
Fixes some of the clang-tidy warnings
clang-analyzer-deadcode.DeadStores
clang-analyzer-cplusplus.NewDelete
clang-analyzer-core.uninitialized.UndefReturn
closes some:#253
ignored in this pr:
/usr/include/boost/smart_ptr/detail/shared_count.hpp:432:24
/usr/include/boost/smart_ptr/detail/shared_count.hpp:443:24
51 in build/src/parser
gtest ones
src/fdr/teddy_compile.cpp:600:5 refactoring on way
src/fdr/fdr_compile.cpp:209:5 refactoring on way
256b wide SVE vectors allow some simplification of truffle. Up to 40%
speedup on graviton3. Going from 12500 MB/s to 17000 MB/s onhe
microbenchmark.
SVE2 also offer this capability for 128b vector with a speedup around
25% compared to normal SVE
Add unit tests and benchmark for this wide variant
256b wide SVE vectors allow some simplification of truffle.
Up to 40% speedup on graviton3. Going from 12500 MB/s to 17000 MB/s
onhe microbenchmark.
SVE2 also offer this capability for 128b vector with a speedup around
25% compared to normal SVE
Add unit tests and benchmark for this wide variant
Signed-off-by: Yoan Picchi <yoan.picchi@arm.com>
subtely clever (or else totally useless all these years), when we
see which of the two we might delete that assert entirely. for now
put it back as it was.
