-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Missed optimization: llvm unable to remove bounds check #48253
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
Comments
I compiled to LLVM IR and cleaned up the result a bit and put it through alive2; Assuming I did this right this verifies that there aren't any subtle UB or poison edge cases here, the proposed straightforward optimization is correct at the LLVM layer. |
If we can prove that an addition without wrap flags won't wrap, decompse the operation. Issue #48253
After 66400fc, this should get optimized as expected with |
Great, thank you! I guess this will be closed when #49344 is completed? |
Yes. I' planning to propose the pass to be enabled by default soon. |
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
Uh oh!
There was an error while loading. Please reload this page.
Extended Description
https://godbolt.org/z/vEfPYj (also below)
LLVM should be able to remove the branch that leads to the call to abort() -- data.length is known to be the same as block_len, and block_len is known not to be 0. Therefore llvm should know that block_len - is always < data.length.
Source:
generated assembly:
The text was updated successfully, but these errors were encountered: