cmov: impl optimized CmovEq for [u8] [BREAKING]
#1356
Merged
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
tarcieri
force-pushed
the
ctutils/optimized-cmoveq-for-byte-slices
branch
5 times, most recently
from
c844f00 to
e3d1c1d
Compare
Note: version bumped to v0.5.0-pre to denote breaking change (not for release) Perhaps the first and foremost use case for a crate like this (or `subtle` or `ctutils) is comparing byte slices in constant-time, however the existing codegen for this is bad, because it goes a byte-at-a-time, converting them to a `u32` or `u64`, then emitting predication instructions (or using bitwise masking) on each individual byte. Instead this removes the `CmovEq` impl for `[T]` and replaces it with an optimized impl of `CmovEq` for `[u8]`, reusing the code for the optimized `CmovEq` impl for arrays added in #1353. This approach goes in word-sized chunks of the slice, converting them to a word-sized integer (`u32` or `u64`) and using the `CmovEq` impl on those types, which should result in much more efficient code. With this change all of the slice chunking code is now in the `slice` module, which lets us move the vendored copies of `[T]::as_chunks(_mut)` there, get rid of a `utils` module, and rename it back to `macros` (though that's perhaps a misnomer as it contains only one macro). A small change to the `Cmov` impl added in #1354: it panics if the input sizes aren't equal, using the same panic message as `copy_from_slice`.
tarcieri
force-pushed
the
ctutils/optimized-cmoveq-for-byte-slices
branch
from
e3d1c1d to
b795962
Compare
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.
Note: version bumped to v0.5.0-pre to denote breaking change (not for release)
Perhaps the first and foremost use case for a crate like this (or
subtleorctutils) is comparing byte slices in constant-time, however the existing codegen for this is bad, because it goes a byte-at-a-time, converting them to au32oru64`, then emitting predication instructions (or using bitwise masking) on each individual byte.Instead this removes the
CmovEqimpl for[T]and replaces it with an optimized impl ofCmovEqfor[u8], reusing the code for the optimizedCmovEqimpl for arrays added in #1353.This approach goes in word-sized chunks of the slice, converting them to a word-sized integer (
u32oru64) and using theCmovEqimpl on those types, which should result in much more efficient code.With this change all of the slice chunking code is now in the
slicemodule, which lets us move the vendored copies of[T]::as_chunks(_mut)there, get rid of autilsmodule, and rename it back tomacros(though that's perhaps a misnomer as it contains only one macro).A small change to the
Cmovimpl added in #1354: it panics if the input sizes aren't equal, using the same panic message ascopy_from_slice.