Skip to content

Another attempt to make sha1/sha256 states memcpyable - #785

Merged
karel-m merged 1 commit into
developfrom
pr/hash-memcpyable
Jul 31, 2026
Merged

Another attempt to make sha1/sha256 states memcpyable#785
karel-m merged 1 commit into
developfrom
pr/hash-memcpyable

Conversation

@karel-m

@karel-m karel-m commented Jul 30, 2026

Copy link
Copy Markdown
Member

The main idea:

  • using _mm_loadu_si128 instead of _mm_load_si128
  • using _mm_storeu_si128 instead of _mm_store_si128

However, it looks soooo simple that I am not sure whether I have overlooked something.

@karel-m
karel-m requested a review from sjaeckel July 30, 2026 18:20
@karel-m

karel-m commented Jul 30, 2026

Copy link
Copy Markdown
Member Author

ping @MarekKnapek

@MarekKnapek

Copy link
Copy Markdown
Contributor

Yes, looks good, as I mentioned previously in #742 (comment) replacing the aligned mem-loads with unaligned mem-loads should be enough.

Currently, there are still aligned mem-loads present. Not when reading or storing the hash state, but when reading the constants table in SHA-256. The constants table is heavily decorated with macros forcing it to be aligned to 16 bytes. In old C, this is not possible to achieve via any standards means, only with compiler specific means. In newer C, it is possible to achieve this via standards means. So maybe the hash state could be macro decorated also? I believe that if you have a compiler capable of using intrinsics, the same compiler should be able to align a struct stricter than largest fundamental data type. I suggested this before, but it was rejected.

@karel-m
karel-m merged commit a467ea5 into develop Jul 31, 2026
202 checks passed
@karel-m
karel-m deleted the pr/hash-memcpyable branch July 31, 2026 09:10
This was referenced Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants