-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[stdlib] Update Array.subscript to use _modify #19154
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
@swift-ci please smoke benchmark |
@swift-ci please test |
@swift-ci please smoke test compiler performance |
@swift-ci please test source compatibility |
Build failed |
Build failed |
I guess that'll teach me for skipping building the benchmarks 😞 |
@@ -646,31 +647,6 @@ extension Array { | |||
return _buffer.capacity | |||
} | |||
|
|||
/// - Precondition: The array has a native buffer. | |||
@inlinable | |||
@_semantics("array.owner") |
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 we remove optimizer code that checks for this semantics attribute also?
palomino:swift spestov$ git grep kGetArrayOwner
include/swift/SILOptimizer/Analysis/ArraySemantic.h: kGetArrayOwner,
lib/SILOptimizer/Analysis/ArraySemantic.cpp: .Case("array.owner", ArrayCallKind::kGetArrayOwner)
lib/SILOptimizer/Analysis/EscapeAnalysis.cpp: case ArrayCallKind::kGetArrayOwner:
lib/SILOptimizer/LoopTransforms/COWArrayOpt.cpp: case ArrayCallKind::kGetArrayOwner:
lib/SILOptimizer/LoopTransforms/COWArrayOpt.cpp: case ArrayCallKind::kGetArrayOwner:
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.
It's still there in ContiguousArray
and ArraySlice
, which are next up.
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: Swift libraries
How 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 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
|
I did not expect the compile time wins. I wonder why? |
wat |
@swift-ci please test compiler performance |
Build comment file:Summary for master fullUnexpected test results, excluded stats for RxSwift, ChattoAdditions, Wordy, ReactiveSwift Regressions found (see below) Debug-batchdebug-batch briefRegressed (0)
Improved (0)
Unchanged (delta < 1.0% or delta < 100.0ms) (3)
debug-batch detailedRegressed (3)
Improved (1)
Unchanged (delta < 1.0% or delta < 100.0ms) (88)
Releaserelease briefRegressed (0)
Improved (0)
Unchanged (delta < 1.0% or delta < 100.0ms) (3)
release detailedRegressed (0)
Improved (1)
Unchanged (delta < 1.0% or delta < 100.0ms) (22)
|
6214416
to
c154744
Compare
@swift-ci please smoke benchmark |
@swift-ci please smoke test compiler performance |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: Swift libraries
How 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 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
|
Build comment file:Summary for master smoketestUnexpected test results, excluded stats for Kingfisher, ReactiveCocoa No regressions above thresholds Debugdebug briefRegressed (0)
Improved (1)
Unchanged (delta < 1.0% or delta < 100.0ms) (2)
debug detailedRegressed (0)
Improved (0)
Unchanged (delta < 1.0% or delta < 100.0ms) (23)
Releaserelease briefRegressed (0)
Improved (0)
Unchanged (delta < 1.0% or delta < 100.0ms) (3)
release detailedRegressed (0)
Improved (0)
Unchanged (delta < 1.0% or delta < 100.0ms) (23)
|
@airspeedswift I wonder if the memset issue is due to array hoisting failing. It could be that you are changing the pattern we are looking for so the semantic optimization for uniqueness check hoisting is not kicking in. |
_makeMutableAndUnique() // makes the array native, too | ||
_checkSubscript_native(index) | ||
return (_getElementAddress(index), _getOwner_native()) | ||
let address = _buffer.subscriptBaseAddress + index |
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 changed has replaced the call to 'getElementAddress' which is a semantic function with its implementation. This would likely prevent uniqueness hoisting and array bounds check elimination.
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.
Ok let me try putting that back. Seems a shame to have to have a symbol just for doing that.
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.
I already have a fix for this
#19181 should fix the crash and most of the regressions (except XorLoop, which needs more work) |
@swift-ci please smoke benchmark |
@swift-ci please test |
Build failed |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
How 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 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
|
@eeckstein oddly getting a linux-only optimizer assertion now |
@airspeedswift Can you disable the test for linux and file a bug? |
c154744
to
4eead4f
Compare
@swift-ci please smoke test |
Awesome! |
* Switch Array to use subscript _modify * Add _modify to ContiguousArray * XFAIL linux failing test
This switches
Array
from usingmutableAddressWithNativeOwner
to using a yielding_modify