-
Notifications
You must be signed in to change notification settings - Fork 248
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
soft-sha512 code size seems unreasonably high on thumbv7em #561
Comments
#547 may reduce size a bit, but the main reason for the big code size is likely aggressive inlining of round processing code which we use. Our block compressing function compiles down to a completely branchless code, which is usually what we want, but it's not desirable for constrained targets. It may be worth introduce a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm working on an embedded project which needs ed25519 signing, which pulls in sha2 for the sha512 step of the signing procedure. On an
thumbv7em
target, the sha512 implementation appears to consume a very significant chunk of code space:If I use
opt-level = "z"
it is better, but still pretty high:The amounts above seem quite onerous for my target which only has 256kB of flash, and would potentially be a non-starter for targets with even less code storage available.
I suspect it's probably a combination of inlined soft 64-bit integer arithmetic and extreme levels of code generation due to macro expansion.
If improving the code size would be a performance regression on some platforms perhaps an implementation favoring code size gated behind a crate feature flag could be of interest? Like a "32-bit-friendly" version or something I guess.
The text was updated successfully, but these errors were encountered: