LZ4 HC match finder and parsers use direct offset values #1173
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
instead of a virtual past pointer.
instead of a virtual pointer
replaced by direct offset values.
replaced by direct offset value. this virtual pointer was only used in rare _dstSize scenario.
this formalized better the coupling between match length and match offset which were 2 separated variables before.
because ubsan complains even about intermediate pointer arithmetic results (in a simple linear formula with 3 factors for example). use parenthesis to make sure calculations go directly from one valid memory address to another valid memory address value.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Direct offset values replace the former method of "virtual pointers", which could lead to UB in some complex scenarios involving a combination of HC compression, external dictionaries and low memory addresses.
As importantly, it also makes the code a bit easier to read.
The produced compressed data remains strictly bit-identical.
Performance is unchanged on M1+
clang,but it's unfortunately slightly slower on Skylake (both
gcc&clang).Even in latter case, the performance difference remains small (<5%), confined to fastest levels (3-5), and quickly unmeasurable at higher levels.
I'm tempted to favor correctness and readability over the small speed difference, given that these HC levels are not speed-sensitive (as long as performance differences remain within a few %).