-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Reenable opt-level 3 #41967
Reenable opt-level 3 #41967
Conversation
This comment is quite old, let's see what would happen with current MSVC.
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
Tested this locally, everything looks ok, lets's see what AppVeyor says. |
📌 Commit 30383b2 has been approved by |
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.
@ishitatsuyuki did you mean to close this? |
@bors: r+ |
📌 Commit 30383b2 has been approved by |
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.
☀️ 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.