-
Notifications
You must be signed in to change notification settings - Fork 27
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
Enforce target feature #61
base: main
Are you sure you want to change the base?
Conversation
This turns out to be much more challenging than expected: the target_feature disables inlining, which defeats the purpose of an fast hashing algorithm. This is done by design for "safety reasons" I assume. This is unfortunate because with runtime checks the context could have been made safe not to disable inlining. |
Problem(s)
This PR addresses as few points:
platform
#57target-cpu=native
being settarget-cpu=native
not being set at allPossible Solutions
RUSTFLAGS target-feature=+aes,+sse2
...#[target_feature(enable = "feature")]
Chosen solution
This PR change behavior to enforce required target features to fully leverage hardware capabilities. In order not to enforce X86
avx2
/vaes
however we rely on an additional build-time check. This would not work properly in a cross-compiling situation, but I think it is acceptable for now, especially given thatavx2
gxhash only runs on unstable rust anyway.EDIT 1: Inlining?
For some reason, it seems that
#[target_feature(enable = "feature")]
prevents inlining. This is really unfortunate. It also seems that the attribute is "skipped" if the target feature is already enabled. For instance, if passed viaRUSTFLAGS
, of it method is called within a method that itself has the attribute. When the attribute is skipped, we can have inlining.While it is rather annoying, we could deal with this limitation by using the attribute on the gxhash method itself (higher caller), However it's more complex for the
Hasher
part, as inlining on individualwrite_x
methods makes a big difference.