Uh oh!
There was an error while loading. Please reload this page.
Optimize slice.{r}position result bounds check - #45501
Conversation
rust-highfive
commented
Oct 24, 2017
r? @dtolnay (rust_highfive has picked a reviewer for you, use r? to override) |
3a32678 to
b9760deComparedtolnay
commented
Oct 25, 2017
@bors r+ |
bors
commented
Oct 25, 2017
📌 Commit b9760de has been approved by |
dtolnay
commented
Oct 25, 2017
Travis is showing: @bors r- |
b9760de to
3529709Comparearthurprs
commented
Oct 25, 2017
Sorry about that, broken tests... They're fixed now. |
kennytm
commented
Oct 25, 2017
@bors r=dtolnay |
bors
commented
Oct 25, 2017
📌 Commit 3529709 has been approved by |
bors
commented
Oct 26, 2017
⌛ Testing commit 35297095934dd2d0235a61af4dd91f3b304a9b55 with merge 916521726c4b54b3cfe96122e2c98d2b735f819d... |
bors
commented
Oct 26, 2017
💔 Test failed - status-travis |
kennytm
commented
Oct 26, 2017
@bors retry
|
bors
commented
Oct 26, 2017
⌛ Testing commit 35297095934dd2d0235a61af4dd91f3b304a9b55 with merge 18d66a16d23811fffa2aefad15122c676b7b7f23... |
bors
commented
Oct 26, 2017
💔 Test failed - status-travis |
kennytm
commented
Oct 26, 2017
Same error. It's legit then. @arthurprs Could you figure out what triggers #44899 here, and workaround it? |
3529709 to
d2dc4a4Comparearthurprs
commented
Oct 26, 2017
I moved the assume to the end. Can we try again? |
There was a problem hiding this comment.
Thanks. I ran out of caffeine ☕
d2dc4a4 to
f014dc1Comparef014dc1 to
9591262Comparearthurprs
commented
Oct 29, 2017
Ok, this is definitely not safe. |
There was a problem hiding this comment.
(This one should be before += 1 to be correct.)
There was a problem hiding this comment.
Good point. Moving it before the mutation probably kills the optimization though.
There was a problem hiding this comment.
@arthurprs What if you make it assume(0 < index && index <= len)
There was a problem hiding this comment.
We can try that too. Lets try a few more things.
bluss
commented
Oct 29, 2017
A bit of a tangential thought, maybe we should have a version of assume that's like debug_assert in debug builds and assume in release builds. I'm a proponent of debug checking almost all unsafe code. |
ecb4f4a to
896e6a5Compare896e6a5 to
c8d3814Comparescottmcm
commented
Oct 29, 2017
Is there a way to have a test for this? I have a PR that will conflict massively with this, and selfishly I'd like an easy way to ensure I don't regress it by accident. Another thought: is this something that should be done for everything that's |
kennytm
commented
Oct 30, 2017
@arthurprs Edit the |
arthurprs
commented
Oct 30, 2017
It failed in both musl builds :sad: Any ideas?
|
I'm gonna wait for #45595 to get in so I can try more combinations. I'm not felling hopeful though 😞 |
kennytm
commented
Nov 1, 2017
@arthurprs Have you tried to reproduce locally via Docker? Just run |
arthurprs
commented
Nov 1, 2017
I gave up trying, I keep getting |
dtolnay
commented
Nov 13, 2017
I am closing the PR because it doesn't look like it is being worked on. I filed #45964 to follow up and try again. It seems like |
…k, r=dtolnay
Optimize slice.{r}position result bounds check
Second attempt of rust-lang#45501Fixesrust-lang#45964
Demo: https://godbolt.org/g/N4mBHpUse the slice length to hint the optimizer about iter.position result Using the len of the iterator doesn't give the same result. That's also why we can't generalize it to all TrustedLen iterators. Problem demo: https://godbolt.org/g/MXg2ae Fix demo: https://godbolt.org/g/P8q5aZ Second attempt of #47333 Third attempt of #45501Fixes#45964
Try to fix 48116 and 48192 The bug #48116 happens because of a misoptimization of the `import_path_to_string` function, where a `names` slice is empty but the `!names.is_empty()` branch is executed. https://github.com/rust-lang/rust/blob/4d2d3fc5dadf894a8ad709a5860a549f2c0b1032/src/librustc_resolve/resolve_imports.rs#L1015-L1042 Yesterday, @eddyb had locally reproduced the bug, and [came across the `position` function](https://mozilla.logbot.info/rust-infra/20180214#c14296834) where the `assume()` call is found to be suspicious. We have *not* concluded that this `assume()` causes #48116, but given [the reputation of `assume()`](#45501 (comment)), this seems higher relevant. Here we try to see if commenting it out can fix the errors. Later @alexcrichton has bisected and found a potential bug [in the LLVM side](#48116 (comment)). We are currently testing if reverting that LLVM commit is enough to stop the bug. If true, this PR can be reverted (keep the `assume()`) and we could backport the LLVM patch instead. (This PR also includes an earlier commit from #48127 for help debugging ICE happening in compile-fail/parse-fail tests.) The PR also reverts #48059, which seems to cause #48192. r? @alexcrichton cc @eddyb, @arthurprs (#47333)
All the unrolling makes it hard for llvm to optimize it out.
Sample https://godbolt.org/g/R9nLvC