-
-
Notifications
You must be signed in to change notification settings - Fork 308
Remove UNALIGNED_OK checks #1828
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -111,6 +111,7 @@ endmacro() | |
|
|
||
| macro(add_undefined_sanitizer) | ||
| set(known_checks | ||
| alignment | ||
| array-bounds | ||
| bool | ||
| bounds | ||
|
|
@@ -137,10 +138,6 @@ macro(add_undefined_sanitizer) | |
| vptr | ||
| ) | ||
|
|
||
| # Only check for alignment sanitizer flag if unaligned access is not supported | ||
| if(NOT WITH_UNALIGNED) | ||
| list(APPEND known_checks alignment) | ||
| endif() | ||
| # Object size sanitizer has no effect at -O0 and produces compiler warning if enabled | ||
| if(NOT CMAKE_C_FLAGS MATCHES "-O0") | ||
| list(APPEND known_checks object-size) | ||
|
|
@@ -153,12 +150,6 @@ macro(add_undefined_sanitizer) | |
| add_compile_options(-fsanitize=${supported_checks}) | ||
| add_link_options(-fsanitize=${supported_checks}) | ||
|
|
||
| # Group sanitizer flag -fsanitize=undefined will automatically add alignment, even if | ||
| # it is not in our sanitize flag list, so we need to explicitly disable alignment sanitizing. | ||
| if(WITH_UNALIGNED) | ||
| add_compile_options(-fno-sanitize=alignment) | ||
| endif() | ||
|
|
||
|
Comment on lines
-156
to
-161
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Awesome, hopefully by removing this bit we'll have some coverage for anything we've missed with CI.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, looks like we already found an invalid alignment access at crc32_acle.c:52
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hah yep. Easy fix, hopefully it generates the same code like I'd expect it to. |
||
| add_common_sanitizer_flags() | ||
| else() | ||
| message(STATUS "Undefined behavior sanitizer is not supported") | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -29,21 +29,13 @@ | |
| # define HASH_CALC_MASK HASH_MASK | ||
| #endif | ||
| #ifndef HASH_CALC_READ | ||
| # ifdef UNALIGNED_OK | ||
| # if BYTE_ORDER == LITTLE_ENDIAN | ||
| # define HASH_CALC_READ \ | ||
| memcpy(&val, strstart, sizeof(val)); | ||
| # else | ||
| # define HASH_CALC_READ \ | ||
| memcpy(&val, strstart, sizeof(val)); \ | ||
| val = ZSWAP32(val); | ||
| # endif | ||
| # if BYTE_ORDER == LITTLE_ENDIAN | ||
| # define HASH_CALC_READ \ | ||
| memcpy(&val, strstart, sizeof(val)); | ||
| # else | ||
| # define HASH_CALC_READ \ | ||
| val = ((uint32_t)(strstart[0])); \ | ||
| val |= ((uint32_t)(strstart[1]) << 8); \ | ||
| val |= ((uint32_t)(strstart[2]) << 16); \ | ||
| val |= ((uint32_t)(strstart[3]) << 24); | ||
| memcpy(&val, strstart, sizeof(val)); \ | ||
| val = ZSWAP32(val); | ||
|
Comment on lines
-43
to
+38
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks good, I wonder of GCC was missing this obvious byteswap idiom. If so, this should actually end up being faster, as I think GCC will probably translate this to movbe on x86. |
||
| # endif | ||
| #endif | ||
|
|
||
|
|
||
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.
I kind of speculate this loop here doesn't actually need to exist. There may be some performance benefit in a niche case for keeping it if say, the ISA has an unaligned write penalty but otherwise permits arbitrary alignment. Then the compiler would likely generate simple writes that happen to be at word aligned offsets. Of course, there's likely going to be unaligned access in one way or another, either the read, the write, or both.
Maybe I should see if things are impacted on the G5, which will use the C implementations of these things, supports unaligned writes from GPRs, and I think has a performance penalty for doing so.
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.
If we could leave out this loop on some of the architectures, that'd certainly be nice for performance.
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.
This was added due to a hang on macOS: #1031
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.
Now that we don't directly access anything unaligned anymore I suspect it's not needed but I don't have a Mac os machine to test it with. Was this with aarch64 or x86?
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.
I'm not certain. It looks like it was in a code coverage build.