-
Notifications
You must be signed in to change notification settings - Fork 11
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
Target request: x86_64 without ADX #143
Comments
There is a couple things here
Hard to tell. I wonder if it would make sense to dive into that now or refactor beforehand to have some sort of capability system, based on which CryptOpt can emit code constructs. (Thinking of bringing this to Go-Assembly or ARM). |
Ok, thank you for the overview! Adding support for more constrained register allocation seems to be the main challenge here, and I don't feel up to tackling it right now. |
It would be nice to use CryptOpt to generate plain x86_64 code that does not depend on the ADX extension, to serve as a fallback from CryptOpt-optimized fast assembly in distributed binaries.
This is a requirement for deployment in BoringSSL, andI hear it may be relevant to adoption of mit-plv/fiat-crypto#1582 as well.I am thinking of use of CryptOpt in this context as primarily an assurance benefit, though if it's decently fast still, even better.
I would be happy to do the work for adapting CryptOpt here if you think that this would be a good first project to hack on in the CryptOpt codebase.
The text was updated successfully, but these errors were encountered: