Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Stability" of the -C passes and -C llvm-args flags #40063

Open
japaric opened this issue Feb 23, 2017 · 3 comments
Open

"Stability" of the -C passes and -C llvm-args flags #40063

japaric opened this issue Feb 23, 2017 · 3 comments
Labels
A-cranelift Things relevant to the [future] cranelift backend A-gcc Things relevant to the [future] GCC backend A-stability Area: `#[stable]`, `#[unstable]` etc. C-bug Category: This is a bug. I-needs-decision Issue: In need of a decision. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.

Comments

@japaric
Copy link
Member

japaric commented Feb 23, 2017

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

@nagisa
Copy link
Member

nagisa commented Feb 23, 2017

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.

@alexcrichton
Copy link
Member

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.

@Manishearth
Copy link
Member

Yeah, I'm open to that. cargo-fuzz does directly pass some llvm-args down though.

@Mark-Simulacrum Mark-Simulacrum added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed T-tools labels May 24, 2017
@Mark-Simulacrum Mark-Simulacrum added C-bug Category: This is a bug. A-stability Area: `#[stable]`, `#[unstable]` etc. I-needs-decision Issue: In need of a decision. labels Jul 27, 2017
@Centril Centril added the A-cranelift Things relevant to the [future] cranelift backend label Mar 12, 2020
@bjorn3 bjorn3 added the A-gcc Things relevant to the [future] GCC backend label Oct 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cranelift Things relevant to the [future] cranelift backend A-gcc Things relevant to the [future] GCC backend A-stability Area: `#[stable]`, `#[unstable]` etc. C-bug Category: This is a bug. I-needs-decision Issue: In need of a decision. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants