-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Use an explicit unsigned comparison for span index checks #83150
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
base: main
Are you sure you want to change the base?
Use an explicit unsigned comparison for span index checks #83150
Conversation
@swift-ci test |
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.
This seems to be the same underlying issue as rdar://154950810 for which @eeckstein has a PR - #82804
This change looks good as well especially if you plan to cherry-pick
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.
We should have the same changes in RawSpan
and MutableRawSpan
.
I'd already written the bounds checks that way in RawSpan
and MutableRawSpan
, so no change needed there.
@meg-gupta right, hopefully we can land #82804 and fix the problem more generally; this is a stop-gap |
@swift-ci smoke test |
LLVM ought to be able to do this transformation for us, but it currently fails to do so. We can code around it easily enough.
And apply the unsigned-compare optimization one other place that I missed the first time, as revealed by the new tests.
24e2288
to
1bd4562
Compare
@swift-ci smoke test |
LLVM can't do it because it doesn't know that
No, it's a different issue.
Yes, we can. We can add
and add a small peephole optimization which takes this constraint into account for converting the two comparisons into a single one. |
If we pass the information of _assumeNonNegative to LLVM, LLVM can do the work for us: (last two commits of) #83172 |
Looking at the macOS failure here, we're getting a null pointer check that we also absolutely should not have (due to the invariant that the pointer may only be null when count is zero). However, that does not reproduce at desk for me. I assume this is due to the stdlib being built with |
The asserts introduce null pointer checks that make the test too fragile.
f731e1d
to
d0506e4
Compare
@swift-ci smoke test |
@swift-ci smoke test macOS |
LLVM ought to be able to do this transformation for us, but it currently fails to do so. We can code around it easily enough.