Disable LLVM verification by default

[nikic]

Currently -Z no-verify only controls IR verification prior to LLVM codegen, while verification is performed unconditionally both before and after linking with (Thin)LTO.

Also wondering what the sentiment is on disabling verification by default (and e.g. only enabling it on ALT builds with assertions). This does not seem terribly useful outside of rustc development and it does seem to show up in profiles (at something like 3%).

EDIT: A table showing the various configurations and what is enabled when.

Configuration	Dynamic verification performed	LLVM static assertions compiled in
alt builds		yes
nightly builds		no
stable builds		no
CI builds
dev builds in a checkout

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[pietroalbini]

Ping from triage @pnkfelix! This PR needs your review.

[TimNN]

Ping from triage, @pnkfelix / @rust-lang/compiler, this PR needs your review.

[oli-obk]

Also wondering what the sentiment is on disabling verification by default (and e.g. only enabling it on ALT builds with assertions). This does not seem terribly useful outside of rustc development and it does seem to show up in profiles (at something like 3%).

Sidenote: I do dislike the !config.no_verify condition.

If you change this to a verify (and also the flag), then it would be off by default. 3% gains seem nice, let's do it and do a bors perf run

[nikic]

I've pushed a variant that renames -Z no-verify to -Z verify-llvm-ir.

Should I add a config.toml flag for this as well?

[oli-obk]

Should I add a config.toml flag for this as well?

seems sensible, people will want to turn this on for debugging llvm crashes. Can we turn this on on the dev-channel automatically?

[nikic]

I've added an (untested) implementation of the config.toml flag. What does enabling it on the dev-channel mean?

[oli-obk]

@bors try

let's do a perf run

[bors]

⌛ Trying commit 3f18a41 with merge 6ba43c9...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[pietroalbini]

cc @Mark-Simulacrum

[Mark-Simulacrum]

Perf queued.

[nikic]

Perf results: http://perf.rust-lang.org/compare.html?start=cd1105437cd433c12ae5132c9632e01d387b2384&end=6ba43c91a8c395f7247a7605c23dfcb028c0bfc9&stat=instructions%3Au

So 1-3% improvement across the board (apart from check builds, which don't touch LLVM).

[pietroalbini]

Ping from triage @pnkfelix! This PR needs your review.

[pnkfelix]

I'm a little wary of turning off verification unconditionally across the board.

I understand the sentiment that it is only useful for compiler development, but in practice I think it has caught bugs for us.

Could we perhaps leave verification on by default in the nightly channel, and turn it off by default in the stable (and beta?) channels?

Nominating for discussion at rustc team meeting.

[pnkfelix]

@bors r+

[bors]

📌 Commit 3f18a41 has been approved by pnkfelix

[bors]

⌛ Testing commit 3f18a41 with merge 63d9e0003894440cad59003a0938d4c30a4d6f53...

[bors]

💔 Test failed - status-travis

[rust-highfive]

The job arm-android of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[01:31:42] thread '<unnamed>' panicked at 'specified instant was later than self', libstd/sys/unix/time.rs:292:17
[01:31:42] test time::tests::system_time_math ... ok
[01:31:47] test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok
[01:31:48] test collections::hash::map::test_map::test_lots_of_insertions ... ok
[01:32:18] test process::tests::test_process_output_fail_to_start ... test process::tests::test_process_output_fail_to_start has been running for over 60 seconds
No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[rust-highfive]

The job arm-android of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[01:31:42] thread '<unnamed>' panicked at 'specified instant was later than self', libstd/sys/unix/time.rs:292:17
[01:31:42] test time::tests::system_time_math ... ok
[01:31:47] test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok
[01:31:48] test collections::hash::map::test_map::test_lots_of_insertions ... ok
[01:32:18] test process::tests::test_process_output_fail_to_start ... test process::tests::test_process_output_fail_to_start has been running for over 60 seconds
No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[kennytm]

@bors retry #43283

[bors]

⌛ Testing commit 3f18a41 with merge 11432ba...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: pnkfelix
Pushing 11432ba to master...

[nnethercote]

perf.rust-lang.org results show 1--3% speedups on lots of opt and debug benchmark builds:
https://perf.rust-lang.org/compare.html?start=989fa053895a27fd40896335224b619843b7e58a&end=66787e05242d86e0bcfa227265559330c45cdc42&stat=instructions:u

Nice work!

[gnzlbg]

Is there a nightly build with all verification, assertions (debug_asserts in rustc, in std, ...), LLVM assertions, etc. turned on that one can use during development? Like every now and then LLVM crashes and the first step to debug the issue is "recompile the world with LLVM with assertions enabled", which basically adds over one hour of cost upfront to start debugging an issue that might just end up being an user error. I would find something like rustup default nightly-dev very helpful even if we only would keep around the artifacts for the last nightly.

[Mark-Simulacrum]

I don't believe nightly builds exist but you can use https://crates.io/crates/rustup-toolchain-install-master with the --alt flag to get what you want I think, though not sure if all of what you want is enabled in those (I think debug asserts in rustc might not be).