Skip to content

Bound checks not eliminated in simple cases #39220

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

Closed
ghost opened this issue Jan 21, 2017 · 3 comments
Closed

Bound checks not eliminated in simple cases #39220

ghost opened this issue Jan 21, 2017 · 3 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ghost
Copy link

ghost commented Jan 21, 2017

I've found several simple cases where bound checks do not get eliminated: https://is.gd/OMzVUa

There are four variants of the same piece of code. It baffles me why bound checks don't get eliminated in the first three functions, and they finally do in the fourth (the function compiles to noop).

Any ideas?

@arthurprs
Copy link
Contributor

arthurprs commented Feb 24, 2017

Probably related to under/overflow confusion by the optimizer. Noticed the same when I was trying to optimize bounds check in binary search.

@Mark-Simulacrum Mark-Simulacrum added the I-slow Issue: Problems and improvements with respect to performance of generated code. label May 24, 2017
@Mark-Simulacrum Mark-Simulacrum added C-enhancement Category: An issue proposing an enhancement or a PR with one. and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Jul 26, 2017
@nikic
Copy link
Contributor

nikic commented Dec 24, 2018

The bounds checks are optimized away since rust 1.25, see https://rust.godbolt.org/z/xTXz0n. However, there are two peculiarities:

a) In 1.25 the whole function is optimized away, but since 1.28 this is no longer the case. This looks like a SROA failure.

b) In nightly first and second are merged, but fourth isn't, even though the IR is strictly the same. This looks like a MergeFuncs bug.

@jonas-schievink jonas-schievink added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 17, 2020
@KamilaBorowska
Copy link
Contributor

KamilaBorowska commented Jul 4, 2022

This appears to be fixed. first, second and fourth are merged. third is correctly optimized to always panic as a - 1 >= 0 isn't a correct check as a is usize.

@nikic nikic closed this as completed Jul 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants