Honor RUSTFLAGS's target-cpu if given

[ryoqun]

Hey, thanks for maintaining a nice crate! This is a tiny build-related PR.

Problem

CPU instruction detection is done at compile time, which isn't compatible for cross-compiling in some case. For example, there is a condition in which compilation is done by a machine with AVX512 and compiled using it and then the binary is transferred to an older machine which lacks the AVX512 support.

Solution

To fix the cross compile issus, we can make reed-solomon's build.rs to accept/honor given RUSTFLAGS, which might have some info for intended CPU architecture in it.

So, we're forcibly reinterpreting RUSTFLAGS's cpu-type as CFLAGS's -march, but it's safe, I think.

That's because as far as I'm aware, the acceptable value of target-cpu is universal across OSS C and Rust toolchains, because rust and clang share the same backend (LLVM), then LLVM was in turn heavily influenced by the GCC because of the compatibility.

Ideally, these should be runtime-based switching for each SIMD implementations, but it would take some more effort than this.

FYI: we're coming from @solana-labs. I'm a collegue with @sakridge, who contributed as well. :) I've created an identical PR for our forked version of this repo: solana-labs#1

[coveralls]

Coverage increased (+0.001%) to 96.259% when pulling bca41bb on ryoqun:guess-target-cpu-for-upstream into 195263f on darrenldl:master.

[codecov]

Codecov Report

Merging #75 into master will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #75   +/-   ##
=======================================
  Coverage   96.27%   96.27%           
=======================================
  Files          10       10           
  Lines        2929     2929           
=======================================
  Hits         2820     2820           
  Misses        109      109           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 195263f...bca41bb. Read the comment docs.

[darrenldl]

Thanks for the PR!

I think the fix is a really nice way of handling that in build.rs (I recall choosing -march=native initially after trial and error and giving up).

However, I'm gonna say that I haven't done much Rust nowadays, and so I'll wait a bit and see if other contributors or users have any more feedback.

[ryoqun]

@darrenldl Thanks for merging!! Now, I'm looking forward to a new patch release, hopefully. :)

[darrenldl]

@ryoqun Thanks for the PR again. I'll finish the required admin work (filling in changelog) and make a release in next 24 hours.

[darrenldl]

@ryoqun 4.0.2 has been published to crates.io

Let me know if there's any problem - kinda doing it in a rush, sorry if I missed some stuff during publishing.

[ruuda]

So, we're forcibly reinterpreting RUSTFLAGS's cpu-type as CFLAGS's -march, but it's safe, I think.

For target-cpu=generic, rustc will accept that, but Clang rejects -march=generic. But this is a minor issue, target-cpu=generic is not the default.