Disable LLVM newPM by default

[nagisa]

This is a temporary solution until we manage to get some sort of a workaround for the rampant inlining behaviour and other issues such as #91128 in place. Expect significant compilation time regressions in other areas, though.

[rust-highfive]

r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

[nagisa]

r? @nikic

[camelid]

Expect significant compilation time regressions in other areas, though.

@bors rollup=never

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

configure: rust.debug-assertions := True
configure: rust.overflow-checks := True
configure: llvm.assertions := True
configure: dist.missing-tools := True
configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
configure: writing `config.toml` in current directory
configure: configure: run `python /checkout/x.py --help`
configure: ---
skip untracked path cpu-usage.csv during rustfmt invocations
skip untracked path src/doc/book/ during rustfmt invocations
skip untracked path src/doc/rust-by-example/ during rustfmt invocations
skip untracked path src/llvm-project/ during rustfmt invocations
Diff in /checkout/compiler/rustc_codegen_llvm/src/back/write.rs at line 400:
) -> bool {
// The new pass manager is causing significant performance issues such as #91128, and is
// therefore disabled in stable versions of rustc by default.
- config
- .new_llvm_pass_manager
- .unwrap_or(false)
+ config.new_llvm_pass_manager.unwrap_or(false)
pub(crate) unsafe fn optimize_with_new_llvm_pass_manager(
Running `"/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/rustfmt" "--config-path" "/checkout" "--edition" "2018" "--unstable-features" "--skip-children" "--check" "/checkout/compiler/rustc_codegen_llvm/src/value.rs" "/checkout/compiler/rustc_codegen_llvm/src/lib.rs" "/checkout/compiler/rustc_codegen_llvm/src/base.rs" "/checkout/compiler/rustc_codegen_llvm/src/abi.rs" "/checkout/compiler/rustc_codegen_llvm/src/back/profiling.rs" "/checkout/compiler/rustc_codegen_llvm/src/consts.rs" "/checkout/compiler/rustc_codegen_llvm/src/back/write.rs" "/checkout/compiler/rustc_codegen_llvm/src/type_of.rs"` failed.
If you're running `tidy`, try again with `--bless`. Or, if you just want to format code, run `./x.py fmt` instead.

[nikic]

Hm, I'm not sure this is a good idea, at least for nightly. I'm afraid this is going to break more than it fixes, as we've only had isolated reports of pathological compile-time regressions.

I don't remember the details, but I'm pretty sure I've seen various nightly-only projects make changes to accommodate the NewPM switch (I think one issue was different pass naming for sanitizers or something?) and switching back and forth would be rather annoying.

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

configure: rust.debug-assertions := True
configure: rust.overflow-checks := True
configure: llvm.assertions := True
configure: dist.missing-tools := True
configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
configure: writing `config.toml` in current directory
configure: configure: run `python /checkout/x.py --help`
configure: ---
skip untracked path cpu-usage.csv during rustfmt invocations
skip untracked path src/doc/book/ during rustfmt invocations
skip untracked path src/doc/rust-by-example/ during rustfmt invocations
skip untracked path src/llvm-project/ during rustfmt invocations
Diff in /checkout/compiler/rustc_codegen_llvm/src/back/write.rs at line 400:
) -> bool {
// The new pass manager is causing significant performance issues such as #91128, and is
// therefore disabled in stable versions of rustc by default.
- config
- .new_llvm_pass_manager
- .unwrap_or(false)
+ config.new_llvm_pass_manager.unwrap_or(false)
pub(crate) unsafe fn optimize_with_new_llvm_pass_manager(
Running `"/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/rustfmt" "--config-path" "/checkout" "--edition" "2018" "--unstable-features" "--skip-children" "--check" "/checkout/compiler/rustc_codegen_llvm/src/va_arg.rs" "/checkout/compiler/rustc_codegen_llvm/src/callee.rs" "/checkout/compiler/rustc_codegen_llvm/src/attributes.rs" "/checkout/compiler/rustc_codegen_llvm/src/builder.rs" "/checkout/compiler/rustc_codegen_llvm/src/back/write.rs" "/checkout/compiler/rustc_codegen_llvm/src/llvm/ffi.rs" "/checkout/compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs" "/checkout/compiler/rustc_codegen_llvm/src/llvm_util.rs"` failed.
If you're running `tidy`, try again with `--bless`. Or, if you just want to format code, run `./x.py fmt` instead.

[nagisa]

I tend to agree. Felix's suggestion was to disable for 1.58 now and then re-enable when we have fixes, but a less disruptive option could be simply landing an equivalent of #91189 sometime next week.

[pnkfelix]

nominating for discussion two weeks from today (2021-12-16), in order to evaluate whether to land by 2021-12-23, or if the problem was addressed by more targetted fix in meantime.

[pnkfelix]

Current theory is that llvm/llvm-project@a8c2ba1 on LLVM's side will address #91128 in a less heavy handed way than outright disabling NewPM.

[nagisa]

We want to backport either this or #92110 to beta.

[pnkfelix]

Discussed in T-compiler meeting. We'll beta-backport this for now, and let #92110 (which as of this comment has not yet landed) bake on nightly for a little while.

@rustbot label: +beta-accepted

[bors]

☔ The latest upstream changes (presumably #91125) made this pull request unmergeable. Please resolve the merge conflicts.

[Mark-Simulacrum]

@nagisa this is targeting master -- but hasn't landed yet there. It looks like some of the discussion indicates we may want to only land this on beta?

It merges cleanly onto beta, so I'm going to backport it there for now.

[nagisa]

Yeah, beta only. We merged a proper fix to master.

Originally this was intended for master as well, but is no longer necessary.

[Mark-Simulacrum]

OK, I'll go ahead and close this PR then -- backport in #92592.