Disable LLVM verification by default by nikic · Pull Request #51230 · rust-lang/rust

nikic · 2018-05-30T20:58:13Z

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 · 2018-05-30T20:58:23Z

r? @pnkfelix

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

emilyalbini · 2018-06-04T10:49:50Z

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

TimNN · 2018-06-12T17:41:01Z

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

oli-obk · 2018-06-12T18:05:10Z

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

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.

This disables IR verification by default.

nikic · 2018-06-12T19:35:14Z

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 · 2018-06-12T19:42:35Z

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 · 2018-06-12T19:45:32Z

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

oli-obk · 2018-06-13T16:46:05Z

@bors try

let's do a perf run

bors · 2018-06-13T16:46:18Z

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

Respect -Z no-verify during LTO 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%).

bors · 2018-06-13T18:38:20Z

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

emilyalbini · 2018-06-13T20:23:35Z

cc @Mark-Simulacrum

Mark-Simulacrum · 2018-06-13T20:33:01Z

Perf queued.

nikic · 2018-06-14T08:48:36Z

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).

emilyalbini · 2018-06-18T09:40:57Z

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

pnkfelix · 2018-06-18T14:48:08Z

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.

bors · 2018-07-10T20:39:40Z

📌 Commit 3f18a41 has been approved by pnkfelix

bors · 2018-07-11T02:44:30Z

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

bors · 2018-07-11T04:50:06Z

💔 Test failed - status-travis

rust-highfive · 2018-07-11T04:50:07Z

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 · 2018-07-11T04:50:39Z

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 · 2018-07-11T10:26:05Z

@bors retry #43283

bors · 2018-07-11T12:12:20Z

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

Disable LLVM verification by default 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 | | |

bors · 2018-07-11T14:14:56Z

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

nnethercote · 2018-07-12T00:01:44Z

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 · 2018-07-12T08:03:03Z

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 · 2018-07-12T13:07:06Z

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).

…crum Improve verify_llvm_ir config option LLVM IR verification has been disabled by default in rust-lang#51230. However, the implementation doesn't quite match what was discussed in the discussion. This patch implements two changes: * Make `verify_llvm_ir` influence the behavior of the compiled rustc binary, rather than just the rustc build system. That is, if `verify_llvm_ir=true`, even manual invocations of the built rustc will verify LLVM IR. * Enable verification of LLVM IR in CI, for non-deploy and deploy-alt builds. This is similar to how LLVM assertions are handled.

rust-highfive assigned pnkfelix May 30, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 30, 2018

Respect -Z no-verify during LTO
78a1644
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.

nikic force-pushed the no-verify-lto branch from 4e691fd to c71ed1bCompare June 12, 2018 19:19

Rename -Z no-verify to -Z verify-llvm-ir
22cf833
This disables IR verification by default.

nikic force-pushed the no-verify-lto branch from c71ed1b to 22cf833Compare June 12, 2018 19:24

Add verify-llvm-ir flag to config.toml
3f18a41

emilyalbini added S-waiting-on-perf Status: Waiting on a perf run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 13, 2018

kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jun 14, 2018

pnkfelix added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-nominated I-needs-decision Issue: In need of a decision. labels Jun 18, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 10, 2018

pnkfelix removed the I-needs-decision Issue: In need of a decision. label Jul 10, 2018

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 11, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 11, 2018

bors merged commit 3f18a41 into rust-lang:masterJul 11, 2018

bors mentioned this pull request Jul 11, 2018
Add Polly support. #51061
Closed

nnethercote mentioned this pull request Jul 12, 2018
Upgrade to LLVM's master branch (LLVM 7) #51966
Merged

nikic mentioned this pull request Oct 13, 2018
Improve verify_llvm_ir config option #55031
Merged

lnicola mentioned this pull request Aug 1, 2020
Move from log to tracing#74726
Merged

moxian mentioned this pull request May 8, 2025
Target features getting erased when using #[export_name] with names of LLVM intrinsics #140822
Open

workingjubilee added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label May 26, 2025

Uh oh!

Uh oh!

Conversation

nikic commented May 30, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented May 30, 2018

Uh oh!

emilyalbini commented Jun 4, 2018

Uh oh!

TimNN commented Jun 12, 2018

Uh oh!

oli-obk commented Jun 12, 2018

Uh oh!

nikic commented Jun 12, 2018

Uh oh!

oli-obk commented Jun 12, 2018

Uh oh!

nikic commented Jun 12, 2018

Uh oh!

oli-obk commented Jun 13, 2018

Uh oh!

bors commented Jun 13, 2018

Uh oh!

bors commented Jun 13, 2018

Uh oh!

emilyalbini commented Jun 13, 2018

Uh oh!

Mark-Simulacrum commented Jun 13, 2018

Uh oh!

nikic commented Jun 14, 2018

Uh oh!

emilyalbini commented Jun 18, 2018

Uh oh!

pnkfelix commented Jun 18, 2018

Uh oh!

bors commented Jul 10, 2018

Uh oh!

bors commented Jul 11, 2018

Uh oh!

bors commented Jul 11, 2018

Uh oh!

rust-highfive commented Jul 11, 2018

Uh oh!

rust-highfive commented Jul 11, 2018

Uh oh!

kennytm commented Jul 11, 2018

Uh oh!

bors commented Jul 11, 2018

Uh oh!

bors commented Jul 11, 2018

Uh oh!

nnethercote commented Jul 12, 2018

Uh oh!

gnzlbg commented Jul 12, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mark-Simulacrum commented Jul 12, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

nikic commented May 30, 2018•
edited
Loading

gnzlbg commented Jul 12, 2018•
edited
Loading