Expose target-cpu/target-feature

[huonw]

rustc won't use e.g. AVX instructions without being told that it's ok to compile to a non-lowest-common-denominator CPU, and programmers may wish to opt-in to these more specialised instructions.

[huonw]

cc #544

[alexcrichton]

Now that cargo rustc is implemented (and this is part of custom target specs), I'm going to close this as I think the need is probably less pressing for now. I'd still like to continue to avoid exposing all flags of the compiler through Cargo itself, and cargo rustc should be a good escape hatch for this behavior for now.

[huonw]

Hm, it was pointed out to me that cargo rustc doesn't quite handle everything. Specifically, AFAIK, it doesn't allow one to easily build dependencies with the given codegen options, which can be pretty important.

(I could be wrong, but reopening so this doesn't get forgotten. Close if I am.)

[alexcrichton]

Yeah cargo rustc is not appropriate for the use case of "I'd like to apply this set of LLVM features to the entire compile", but I also don't think that exposing these flags is the right option. The "correct" way to do that is to create a custom target specification which has the right set of features listed, depending on your use case.

Can you elaborate on what the use case is for this? I would expect that a one-off compile (testing using new instructions) would be done through cargo rustc, but do you want this saved into Cargo.toml, for example? (without switching targets fundamentally).

[huonw]

"Make this binary run as fast as possible here" essentially implies feeding -C target-cpu=native to each crate. I suppose it could be handled via target specs, but that seems... way more difficult than necessary. Maybe a built-in target like cargo build --target=native.

However, that doesn't cover cases like "I'm building for other computers where every CPU is guaranteed to support SSE4.1 (but not necessarily anything later)". It does seem like a custom target may work better for this: e.g. my-data-center-target.json.

Another case I can imagine is running tests/benchmarks with various cpu-... options, but this is maybe less important?

[alexcrichton]

Hm yeah I think those are compelling enough to not be totally covered by cargo rustc + custom target specs. I suspect that "run as fast as possible" typically doesn't require that all crates are compiled with target-cpu=native but rather just one or two particular ones, but the point definitely still stands.

Before we expose something like this I just want to make sure that we have a clear policy on what is/isn't exposed. I don't want all compiler options to become Cargo options in 3 different places (taken to the extreme).

[alexcrichton]

With support for RUSTFLAGS now landed, I'm going to close this in favor of that as I believe it's possible to pass through that vector.