-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Optimize slice.{r}position result bounds check #47333
Conversation
30e7c6c
to
bd4ead6
Compare
src/libcore/slice/mod.rs
Outdated
{ | ||
// The addition might panic on overflow | ||
self.try_fold(0, move |i, x| { | ||
if predicate(x) { LoopState::Break(i) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
failed to resolve. Use of undeclared type or module LoopState
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm changing it to use Result<,>'s instead.
bd4ead6
to
2b77cac
Compare
r? @dtolnay |
2b77cac
to
b95a7b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for sticking with this!
@bors r+ |
📋 Looks like this PR is still in progress, ignoring approval |
Borrowck error. We haven't enabled NLL yet 😄.
|
I see 😢 going for the 5th try now. |
806b403
to
1699dc4
Compare
@bors r=dtolnay |
📌 Commit 1699dc4 has been approved by |
Self: Sized, | ||
P: FnMut(Self::Item) -> bool, | ||
{ | ||
// The addition might panic on overflow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs either Add::add
instead of +
or #[rustc_inherit_overflow_checks]
.
Also, it's a shame there's no way to "call base" here. Would it be worth making a pub(crate)
helper here to avoid duplicating the logic? Or using specialization to do the assume
for all Self: TrustedLen
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the duplication is a concern as these are really small. Having a helper would probably end up adding more lines than saving.
Good points about the overflow and specialization though. I have to test if the assume survives the abstraction/inlining.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't make it work with TrustedLen 😞 https://godbolt.org/g/bFA3tk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for giving it a try! Good to see this get in 🙂
1699dc4
to
0b56ab0
Compare
I added a |
@bors r=dtolnay |
📌 Commit 0b56ab0 has been approved by |
…k, r=dtolnay Optimize slice.{r}position result bounds check Second attempt of rust-lang#45501 Fixes rust-lang#45964 Demo: https://godbolt.org/g/N4mBHp
Apparently this didn't work 😢 Demo: https://godbolt.org/g/MXg2ae It has to do with Using |
Use 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 #45501 Fixes #45964
Removed the `assume()` which we assumed is the cause of misoptimization in issue rust-lang#48116.
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)
Second attempt of #45501
Fixes #45964
Demo: https://godbolt.org/g/N4mBHp