Open japaric opened 7 years ago
These are all LLVM specific or closely tied to LLVM:
-C lto -- perform LLVM link-time optimizations
-C target-cpu=val -- select target processor (rustc --print target-cpus for details)
-C target-feature=val -- target specific attributes (rustc --print target-features for details)
-C passes=val -- a list of extra LLVM passes to run (space separated)
-C llvm-args=val -- a list of arguments to pass to llvm (space separated)
-C save-temps -- save all temporary output files during compilation
-C no-prepopulate-passes -- don't pre-populate the pass manager with a list of passes
-C no-vectorize-loops -- don't run the loop vectorization optimization passes
-C no-vectorize-slp -- don't run LLVM's SLP vectorization pass
-C no-integrated-as -- use an external assembler rather than LLVM's integrated one
-C no-redzone=val -- disable the use of the redzone
-C relocation-model=val -- choose the relocation model to use (rustc --print relocation-models for details)
-C code-model=val -- choose the code model to use (rustc --print code-models for details)
-C remark=val -- print remarks for these optimization passes (space separated, or "all")
-C inline-threshold=val -- set the inlining threshold for
The fact that these are codegen flags should be indicative of some of these being LLVM-specific and making these stable-ish was a decision made early on, back when multiple backends wasn’t even in the books.
cargo-fuzz
project itself does not consider these to be stable in any way, but it is certainly possible to make cargo-fuzz
run on stable (without -Z flags) as things are now, even though it is very LLVM-specific.
My personal preference here is the last one mentioned, adding specific options for these various intents (e.g. -Z fuzz
and -Z code-coverage
).
cc @Manishearth for cargo-fuzz
@nagisa is right though that it's not just limited to these, this is indeed a pervasive problem with -C
right now.
Yeah, I'm open to that. cargo-fuzz does directly pass some llvm-args down though.
These flags are part of the stable
rustc
CLI but they let you tap into LLVM internals that we can't guarantee the stability of. Known usages of these flags include:Generating code coverage files. Works on stable
Fuzzing (
cargo fuzz
). This additionally requires using a sanitizer so it requires nightly.Concerns:
An LLVM upgrade may break the functionality exposed by these flags. An LLVM pass may be removed or renamed, the code coverage format may change, etc.
These flags may pose an obstacle for the adoption of non-LLVM backends (like Cranelift). For example,
-C llvm-args
has no meaning for the Cranelift backend.We discussed this a bit towards the end of the last tools meeting. Some ways to communicate the unstability of these flags were brought up:
Discourage their use. Something along these lines:
-C help
, and print a warning if they are used-Z unstable-options
flag.Document what are the real stability guarantees of the functionality exposed by
-C
flags.Provide more targeted unstable
-Z
flags for the LLVM functionality that can be accessed through these flags and encourage users to use those instead the-C
ones. For example,-Z fuzz
,-Z code-coverage
, etc.cc @rust-lang/tools