Skip to content
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

Fix optimization regressions for operations on [x; n]-initialized arrays. #36124

Merged
merged 1 commit into from
Sep 4, 2016

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Aug 29, 2016

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.

@rust-highfive
Copy link
Collaborator

r? @aturon

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

@bors
Copy link
Contributor

bors commented Aug 30, 2016

☔ The latest upstream changes (presumably #36117) made this pull request unmergeable. Please resolve the merge conflicts.

@bluss
Copy link
Member

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
Copy link
Member Author

eddyb commented Aug 30, 2016

@bluss You sure? Overflow shenanigans apply to both pointers and integers.
With !=, the distance for a monotonic loop is guaranteed to be end - start.
But with < or <= you don't know the end directly, you have to infer it (and sometimes you can't).
You can't even know if it loops at least once!
That is, start != start + len iff len != 0 whereas start < start + len depends on start too.
In our case, it would be UB to cross the end of the address space, but still, it's more complicated.

@eddyb
Copy link
Member Author

eddyb commented Aug 30, 2016

On IRC @nrc seems to think that it's easier to see what perf impact this has by getting it merged.
Also, @arielb1 mentioned that GVN is so fast we likely won't notice any change at all.

r? @alexcrichton

@rust-highfive rust-highfive assigned alexcrichton and unassigned aturon Aug 30, 2016
@alexcrichton
Copy link
Member

Ok I've merged the LLVM commit, @eddyb wanna update the commit here?

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Aug 31, 2016

📌 Commit f5c7752 has been approved by alexcrichton

@eddyb eddyb added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 1, 2016
@bors
Copy link
Contributor

bors commented Sep 2, 2016

⌛ Testing commit f5c7752 with merge 2c7fd85...

@bors
Copy link
Contributor

bors commented Sep 2, 2016

💔 Test failed - auto-win-gnu-32-opt-rustbuild

@alexcrichton
Copy link
Member

@bors: retry

On Fri, Sep 2, 2016 at 8:31 AM, bors notifications@github.com wrote:

💔 Test failed - auto-win-gnu-32-opt-rustbuild
https://buildbot.rust-lang.org/builders/auto-win-gnu-32-opt-rustbuild/builds/2381


You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#36124 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAD95L16oxTmyMa_205S9Kn-zbW4feQPks5qmEE3gaJpZM4JwAzX
.

@bors
Copy link
Contributor

bors commented Sep 4, 2016

⌛ Testing commit f5c7752 with merge 1ca1de6...

bors added a commit that referenced this pull request 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 bors merged commit f5c7752 into rust-lang:master Sep 4, 2016
@eddyb eddyb deleted the fast-array-init branch September 4, 2016 04:57
@eddyb
Copy link
Member Author

eddyb commented Sep 8, 2016

@alexcrichton @nrc @nikomatsakis This caused a 4% regression in bootstrap. Hopefully it's worth it.

@nikomatsakis
Copy link
Contributor

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

@brson brson mentioned this pull request Sep 19, 2016
@pnkfelix
Copy link
Member

pnkfelix commented Sep 21, 2016

From skimming the perf benchmarks (rather than bootstrap) times, I think we can accept the risk associated with backporting this.


(There is a weird regression of the piston-image-0.10.3 benchmark, but if I understand the graph correctly, that is due to a commit that came after this PR...)

  • Never mind this note; the timing for piston-image-0.10.3 is zero before this point, which I interpret as meaning that it wasn't actually being run at all.
  • @nrc if you can, you may want to consider not rendering the points that are assigned a time of zero.

@pnkfelix pnkfelix mentioned this pull request Sep 21, 2016
@@ -52,7 +52,7 @@ pub fn slice_for_each<'blk, 'tcx, F>(bcx: Block<'blk, 'tcx>,
let current = Phi(header_bcx, val_ty(start), &[start], &[bcx.llbb]);

let keep_going =
ICmp(header_bcx, llvm::IntULT, current, end, DebugLoc::None);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only line that has to be applied to beta for backport.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beta is on LLVM commit further ahead now due to previous backport.

@nikomatsakis nikomatsakis added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Sep 21, 2016
@nikomatsakis
Copy link
Contributor

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
Copy link
Contributor

brson commented Sep 21, 2016

I've started a backport.

@brson brson removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants