Skip to content

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

Merged
merged 1 commit into from
Oct 27, 2021

Conversation

eeckstein
Copy link
Contributor

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

…" 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
@eeckstein
Copy link
Contributor Author

@swift-ci test

@eeckstein
Copy link
Contributor Author

@swift-ci benchmark

@eeckstein eeckstein requested a review from gottesmm October 27, 2021 12:22
@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - bec687d

@swift-ci
Copy link
Contributor

Performance (x86_64): -O

Regression OLD NEW DELTA RATIO
FlattenListFlatMap 4840 5653 +16.8% 0.86x (?)
StringBuilder 307 331 +7.8% 0.93x (?)
 
Improvement OLD NEW DELTA RATIO
LessSubstringSubstring 43 39 -9.3% 1.10x (?)
String.data.LargeUnicode 125 114 -8.8% 1.10x (?)
EqualStringSubstring 42 39 -7.1% 1.08x (?)
EqualSubstringString 42 39 -7.1% 1.08x
ConvertFloatingPoint.MockFloat64Exactly2 28 26 -7.1% 1.08x (?)

Code size: -O

Regression OLD NEW DELTA RATIO
NibbleSort.o 14847 15231 +2.6% 0.97x

Performance (x86_64): -Osize

Improvement OLD NEW DELTA RATIO
FlattenListFlatMap 6299 4354 -30.9% 1.45x (?)
ObjectiveCBridgeStubToNSStringRef 167 150 -10.2% 1.11x (?)
LessSubstringSubstring 44 40 -9.1% 1.10x (?)
EqualSubstringSubstring 43 40 -7.0% 1.07x (?)
EqualStringSubstring 43 40 -7.0% 1.07x (?)
EqualSubstringSubstringGenericEquatable 43 40 -7.0% 1.07x (?)
EqualSubstringString 43 40 -7.0% 1.07x (?)
LessSubstringSubstringGenericComparable 43 40 -7.0% 1.07x (?)
ObjectiveCBridgeFromNSDictionaryAnyObjectForced 10650 9950 -6.6% 1.07x (?)

Code size: -Osize

Regression OLD NEW DELTA RATIO
NibbleSort.o 14297 14450 +1.1% 0.99x

Performance (x86_64): -Onone

Improvement OLD NEW DELTA RATIO
DataToStringSmall 5000 4650 -7.0% 1.08x (?)

Code size: -swiftlibs

How to read the data The 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
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

@eeckstein
Copy link
Contributor Author

@swift-ci smoke test linux

Copy link
Contributor

@gottesmm gottesmm left a 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 :
Copy link
Contributor

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 :
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants