-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Missed optimization leading to inability to remove bounds check #49229
Comments
Add -mllvm -enable-constraint-elimination seems to eliminate the bounds check: However, adding:
adds the bounds check back. Interestingly enough, adding:
is fine. |
https://godbolt.org/z/136sWEcj3
@jrmuizel could you check this again? I think the latest version should work fine with the check: https://godbolt.org/z/rno6K1eTs |
This reverts commit 695ce48. The compile-time regression causing the revert has been fixed. Recommit the original patch. Original commit message: The pass should help to close a functional gap when it comes to reasoning about related conditions in a relatively general way. It addresses multiple existing issues (linked below) and the need for a more powerful reasoning system was also discussed recently in https://discourse.llvm.org/t/rfc-alternative-approach-of-dealing-with-implications-from-comparisons-through-pos-analysis/65601/7 On AArch64, the new pass performs ~2000 simplifications on MultiSource,SPEC2006,SPEC2017 with -O3. Compile-time impact: NewPM-O3: +0.20% NewPM-ReleaseThinLTO: +0.32% NewPM-ReleaseLTO-g: +0.28% https://llvm-compile-time-tracker.com/compare.php?from=f01a3a893c147c1594b9a3fbd817456b209dabbf&to=577688758ef64fb044215ec3e497ea901bb2db28&stat=instructions:u Fixes #49344. Fixes #47888. Fixes #48253. Fixes #49229. Fixes #58074. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D135915
Extended Description
(All content available as godbolt: https://godbolt.org/z/s6deqs71h)
Given the following code, llvm should be able to prove that the bounds checks within the loop are never necessary:
However the following code is generated:
The throw_out_of_range exception code should be able to be optimized out.
The text was updated successfully, but these errors were encountered: