Uh oh!
There was an error while loading. Please reload this page.
Fix optimization regressions for operations on [x; n]-initialized arrays. - #36124
Conversation
rust-highfive
commented
Aug 29, 2016
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
bors
commented
Aug 30, 2016
☔ The latest upstream changes (presumably #36117) made this pull request unmergeable. Please resolve the merge conflicts. |
bluss
commented
Aug 30, 2016
Nice find. It should be much better this way, the optimizer prefers < / <= for an integer-counted loop and != for a pointer loop. |
eddyb
commented
Aug 30, 2016
@bluss You sure? Overflow shenanigans apply to both pointers and integers. |
eddyb
commented
Aug 30, 2016
alexcrichton
commented
Aug 31, 2016
Ok I've merged the LLVM commit, @eddyb wanna update the commit here? |
alexcrichton
commented
Aug 31, 2016
@bors: r+ |
bors
commented
Aug 31, 2016
📌 Commit f5c7752 has been approved by |
bors
commented
Sep 2, 2016
⌛ Testing commit f5c7752 with merge 2c7fd85... |
bors
commented
Sep 2, 2016
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
alexcrichton
commented
Sep 2, 2016
@bors: retry On Fri, Sep 2, 2016 at 8:31 AM, bors notifications@github.com wrote:
|
bors
commented
Sep 4, 2016
Fix optimization regressions for operations on [x; n]-initialized arrays. Fixes#35662 by using `!=` instead of `<` as the stop condition for `[x; n]` initialization loops. Also included is eddyb/llvm@cc2009f, a hack to run the GVN pass twice, another time after InstCombine. This hack results in removal of redundant `memset` and `memcpy` calls (from loops over arrays). cc @nrc Can we get performance numbers on this? Not sure if it regresses anything else.
bors
commented
Sep 4, 2016
@alexcrichton@nrc@nikomatsakis This caused a 4% regression in bootstrap. Hopefully it's worth it. |
nikomatsakis
commented
Sep 19, 2016
The patch is tiny. I think it's worth backporting. I don't know what to make of the 4% regression. Could be a lot of things. cc @rust-lang/compiler |
From skimming the perf benchmarks (rather than bootstrap) times, I think we can accept the risk associated with backporting this.
|
| let current = Phi(header_bcx, val_ty(start), &[start], &[bcx.llbb]); | ||
| let keep_going = | ||
| ICmp(header_bcx, llvm::IntULT, current, end, DebugLoc::None); |
There was a problem hiding this comment.
This is the only line that has to be applied to beta for backport.
There was a problem hiding this comment.
Without the LLVM change the regression isn't fully fixed, but yeah, this is the main part of it.
It might be in different places, so searching for IntULT used in an iteration loop condition should help.
There was a problem hiding this comment.
Beta is on LLVM commit further ahead now due to previous backport.
nikomatsakis
commented
Sep 21, 2016
OK, I will go ahead and mark as beta-accepted. Backporter should note that backport can be quite minimum, per @nagisa's comments here. |
brson
commented
Sep 21, 2016
I've started a backport. |
Fixes#35662 by using
!=instead of<as the stop condition for[x; n]initialization loops.Also included is eddyb/llvm@cc2009f, a hack to run the GVN pass twice, another time after InstCombine.
This hack results in removal of redundant
memsetandmemcpycalls (from loops over arrays).cc @nrc Can we get performance numbers on this? Not sure if it regresses anything else.