Open ogxd opened 10 months ago
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.
Until this is a little less fuzzy, let's go for a more developer friendly approach, which is to detect the missing target feature within build.rs
to inform the developer that he must enable some target-feature(s). https://github.com/ogxd/gxhash/pull/62
Problem(s)
This PR addresses as few points:
target-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.