Help optimize out bounds checks in median_of_medians by kornelski · Pull Request #144327 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
LLVM can't see that assert!((v / 200) <= (v / 2)) is always true, so it couldn't remove bounds in median_of_ninthers.
.unwrap() outside of min_index() was losing bounds information. I've even tried assume(index < slice.len()); return Some(index), but it didn't help. Only moving the unwrap() to inside the function seems to keep the range information (and doesn't need assume).
Part of #144326
Currently blocked by #144522
r? @tgross35
rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
Is this something that could get a codegen test to make sure we don't have a jump to a panic? Seems easy to accidentally regress.
A codegen test would be valuable, but these functions are inlined into other functions that still need bounds checks fixed, so I can't realistically codegen tests until more of this work is done.
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
I've implemented further refactorings that should eliminate further bounds checks in theory, but tracking of already-checked ranges of variables turned out to be too fickle in LLVM.
I got stuck at ninther that has 9 variables to check, but LLVM gets amnesia after every else, so this function would have to be full of unsafe. This is blocked by llvm/llvm-project#151078 #144522
I can't add codegen tests, because I can't make LLVM generate good code.
bors added a commit that referenced this pull request
Safer sort partition
This reduces amount of unsafe code in partition(), while generating essentially the same code.
partition() and functions calling it can only run into out-of-bounds issues if the is_less function is buggy, so I've used cold panic_on_ord_violation() to replace various other panics/aborts. This slightly reduces code size, and gives a more relevant error message.
Related to #144327
bors added a commit that referenced this pull request
Safer sort partition
This reduces amount of unsafe code in partition(), while generating essentially the same code.
partition() and functions calling it can only run into out-of-bounds issues if the is_less function is buggy, so I've used cold panic_on_ord_violation() to replace various other panics/aborts. This slightly reduces code size, and gives a more relevant error message.
Related to #144327
bors added a commit that referenced this pull request
Safer sort partition
This reduces amount of unsafe code in partition(), while generating essentially the same code.
partition() and functions calling it can only run into out-of-bounds issues if the is_less function is buggy, so I've used cold panic_on_ord_violation() to replace various other panics/aborts. This slightly reduces code size, and gives a more relevant error message.
Related to #144327
Labels
Status: This is awaiting some action (such as code changes or more information) from the author.
Relevant to the library team, which will review and decide on the PR/issue.