Uh oh!
There was an error while loading. Please reload this page.
Reenable opt-level 3 - #41967
Conversation
This comment is quite old, let's see what would happen with current MSVC.
rust-highfive
commented
May 13, 2017
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
petrochenkov
commented
May 13, 2017
Tested this locally, everything looks ok, lets's see what AppVeyor says. |
bors
commented
May 13, 2017
📌 Commit 30383b2 has been approved by |
ishitatsuyuki
commented
May 13, 2017
Uh, by the way this would probably fail due to a bug hidden by different optimization levels resulting in different metadata. (Fixed in #41639) Anyway, let's see how AppVeyor behaves, if we were lucky enough to not get it cancelled. |
Reenable opt-level 3 This comment is quite old, let's see what would happen with current MSVC. Since there's no AppVeyor test for PR, the best way is to try if it get through homu. I don't recommend doing this in roll-up.
alexcrichton
commented
May 13, 2017
alexcrichton
commented
May 18, 2017
@ishitatsuyuki did you mean to close this? |
alexcrichton
commented
May 19, 2017
@bors: r+ |
bors
commented
May 19, 2017
📌 Commit 30383b2 has been approved by |
bors
commented
May 20, 2017
Reenable opt-level 3 This comment is quite old, let's see what would happen with current MSVC. Since there's no AppVeyor test for PR, the best way is to try if it get through homu. I don't recommend doing this in roll-up.
bors
commented
May 20, 2017
☀️ Test successful - status-appveyor, status-travis |
Heh, as what I expected, this is slightly slower probably due to CPU cache blowing. If we're going to lower the default optimize level, the discussion should be done separately, and the change should apply to all projects. EDIT: I'm not sure if the slowdown is caused by simply running more LLVM passes. We should confirm this with the perf dashboard results. |
Revert "Reenable opt-level 3" This reverts commit 30383b2, from #41967. We believe that this is causing the failures when compiling rustc on 64 bit (which are probably segfaults). cc @ishitatsuyuki
Set opt-level = 3 the third time. This PR reverts #51165 (set -O2 to fix#50867), which reverted #50329 (set -O3), which was second attempt of #48204 (set -O3, closed due to Windows segfault that is fixed now), which reverted #42123 (set -O2 to fix spurious Windows segfaults), which reverted #41967 (set -O3). Last time we've found that setting -O3 regressed the wall time of NLL (#50329 (comment)), so we may need another perf run to confirm. I'd like to check this *after* the LLVM 7 upgrade #51966 has been merged, so marking this as <kbd>S-blocked</kbd> for now.
Set opt-level = 3 the third time. This PR reverts #51165 (set -O2 for fixing #50867), which reverted #50329 (set -O3), which was second attempt of #48204 (set -O3, closed due to Windows segfault that is fixed now), which reverted #42123 (set -O2 to fix spurious Windows segfaults), which reverted #41967 (set -O3). Since we have found the root cause of #50867, this optimization could be tried again. Last time we've found that setting -O3 regressed the wall time of NLL (#50329 (comment)), so we may need another perf run to confirm. I'd like to check this *after* the LLVM 7 upgrade #51966 has been merged, so marking this as <kbd>S-blocked</kbd> for now.
This comment is quite old, let's see what would happen with current MSVC.
Since there's no AppVeyor test for PR, the best way is to try if it get through homu. I don't recommend doing this in roll-up.