"Stability" of the `-C passes` and `-C llvm-args` flags

Opened by Jorge Aparicio at 2022-10-29 13:28:21

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 Cretonne). For example, -C llvm-args has no meaning for the Cretonne 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:
- Stable: remove them from -C help, and print a warning if they are used
- Beta/nightly: show a warning if these flags are used without the -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

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:
  - Stable: remove them from -C help, and print a warning if they are used
  - Beta/nightly: show a warning if these flags are used without the -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
Eduard-Mihai Burtescu at 2018-07-13 17:43:16

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.

Simonas Kazlauskas at 2017-02-23 18:06:01

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.
Alex Crichton at 2017-02-27 18:08:30
Yeah, I'm open to that. cargo-fuzz does directly pass some llvm-args down though.
Manish Goregaokar at 2017-02-27 19:38:07