-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
is-valid-utf8.c tweaks #449
Merged
Merged
Conversation
This file contains 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
sjakobi
approved these changes
Dec 6, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The direction seems reasonable, but the code goes way over my head. Maybe someone else can give you feedback on it.
Bodigrim
force-pushed
the
is-valid-utf8-tweaks
branch
from
December 6, 2021 22:08
42743f6
to
0ebc5d9
Compare
@kozross could you possibly give this a quick look? |
…s because of GHC make build issues
…out vectorised instructions
Bodigrim
force-pushed
the
is-valid-utf8-tweaks
branch
from
December 7, 2021 20:10
0ebc5d9
to
fe9b12c
Compare
kozross
suggested changes
Dec 7, 2021
Bodigrim
added a commit
to Bodigrim/bytestring
that referenced
this pull request
Dec 7, 2021
* Cabal check does not recognise arch(arm64) * is-valid-utf8: use __get_cpuid_count instead of __builtin_cpu_supports because of GHC make build issues * Check SSE2 support in runtime instead of compile time * Avoid code duplication: use bytestring_is_valid_utf8 on any arch without vectorised instructions * Further deduplication * Mark has_foo as static inline
noughtmare
pushed a commit
to noughtmare/bytestring
that referenced
this pull request
Dec 12, 2021
* Cabal check does not recognise arch(arm64) * is-valid-utf8: use __get_cpuid_count instead of __builtin_cpu_supports because of GHC make build issues * Check SSE2 support in runtime instead of compile time * Avoid code duplication: use bytestring_is_valid_utf8 on any arch without vectorised instructions * Further deduplication * Mark has_foo as static inline
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.
This branch was triggered into existence by GHC CI failures, but I used the opportunity to deduplicate some code as well.
The precise issue is that some GHC builds (https://gitlab.haskell.org/ghc/ghc/-/jobs/876320#L4200) are unhappy with our usage of
__cpu_indicator_init
. It's more likely GHCmake
who is at fault here, but fighting it is so difficult. We use__get_cpuid
for CPU capabilities detection in SIMD code forcount
:bytestring/cbits/fpstring.c
Lines 237 to 243 in 12303b8
and I also have good experience with
__get_cpuid
intext
(https://github.com/haskell/text/blob/master/cbits/measure_off.c).This PR replaces
__cpu_indicator_init
with__get_cpuid
. Then we make SSE2 detection a runtime dispatch as well, similar to existing SSSE3 and AVX2 checks. This allows us to use fallback function on any platform, not only x86. Finally, I deduplicated fallback functions - there seems to be no measurable impact except extremely short strings, and I think that code clarity is more important here.