-
Notifications
You must be signed in to change notification settings - Fork 10.5k
ConstantFolding: remove a wrong peephole optimization for signed "< 0" and ">= 0" comparisons #39938
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
Conversation
…" and ">= 0" comparisons The wrong optimization was: fold x < 0 into false, if x is known to be a result of an unsigned operation with overflow checks enabled. It was done under the wrong assumption that the result of an overflow-checked unsigned operation fits into a signed integer and is positive. This is wrong, because the result of an unsigned operation can be larger than Int.max and therefore, when used in a signed integer operation, be re-interpreted as a negative signed value. Fixes a miscompile which resulted in a missing abort on arithmetic overflow. rdar://73596890
@swift-ci test |
@swift-ci benchmark |
Build failed |
Performance (x86_64): -O
Code size: -O
Performance (x86_64): -Osize
Code size: -Osize
Performance (x86_64): -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
@swift-ci smoke test linux |
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.
LGTM. Can you just add some comments to the test cases in a subsequent PR explaining why we don't handle this anymore.
@@ -585,18 +574,11 @@ bb0(%0 : $Builtin.Int64, %1 : $Builtin.Int64): | |||
return %uadd_with_overflow_result : $Builtin.Int64 | |||
} | |||
|
|||
// CHECK-LABEL: sil [ossa] @fold_unsigned_op_with_overflow_lt_zero_destructure : | |||
// CHECK-LABEL: sil [ossa] @dont_fold_unsigned_op_with_overflow_lt_zero_destructure : |
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.
Can you just add a comment here (I am fine in a subsequent PR) that explains why we aren't doing this anymore.
// At the same time x >= 0 is always true under the same conditions. | ||
// | ||
// CHECK-LABEL: sil [ossa] @fold_unsigned_op_with_overflow_lt_zero : | ||
// CHECK-LABEL: sil [ossa] @dont_fold_unsigned_op_with_overflow_lt_zero : |
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.
Same here.
The wrong optimization was: fold x < 0 into false, if x is known to be a result of an unsigned operation with overflow checks enabled.
It was done under the wrong assumption that the result of an overflow-checked unsigned operation fits into a signed integer and is positive.
This is wrong, because the result of an unsigned operation can be larger than Int.max and therefore, when used in a signed integer operation, be re-interpreted as a negative signed value.
Fixes a miscompile which resulted in a missing abort on arithmetic overflow.
rdar://73596890