Skip to content

Fix EscapeAnalysis value_to_bridge_object and strong_copy_unowned_value. #29408

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
Jan 24, 2020
Merged

Fix EscapeAnalysis value_to_bridge_object and strong_copy_unowned_value. #29408

merged 1 commit into from
Jan 24, 2020

Conversation

atrick
Copy link
Contributor

@atrick atrick commented Jan 24, 2020

Noticed via code inspection. This could potentially miscompile, but we
haven't seen that happen to my knowledge.

Both value_to_bridge_object and strong_copy_XXX need to escape their
resulting value.

The implementation seemed to assume that it is conservatively correct
simply to avoid building a connection graph node for an value. This is
not true. Any value that has a pointer type requires a connection
graph node. The only way to be conservative is to create the value
node and point it to an escaping content node.

We can always declare that certain special types are not considered
pointer types, but then we need to handle all conversions from those
types to pointer types by escaping the resulting
pointer. BridgeObjects are often on the performance-critical path.

Noticed via code inspection. This could potentially miscompile, but we
haven't seen that happen to my knowledge.

Both value_to_bridge_object and strong_copy_XXX need to escape their
resulting value.

The implementation seemed to assume that it is conservatively correct
simply to avoid building a connection graph node for an value. This is
*not* true. Any value that has a pointer type requires a connection
graph node. The only way to be conservative is to create the value
node *and* point it to an escaping content node.

We can always declare that certain special types are not considered
pointer types, but then we need to handle all conversions from those
types to pointer types by escaping the resulting
pointer. BridgeObjects are often on the performance-critical path.
@atrick atrick requested a review from eeckstein January 24, 2020 00:49
@atrick
Copy link
Contributor Author

atrick commented Jan 24, 2020

@swift-ci test

@atrick
Copy link
Contributor Author

atrick commented Jan 24, 2020

@swift-ci test source compatibility

@atrick
Copy link
Contributor Author

atrick commented Jan 24, 2020

@swift-ci benchmark

@swift-ci
Copy link
Contributor

Performance: -O

Code size: -O

Performance: -Osize

Code size: -Osize

Performance: -Onone

Regression OLD NEW DELTA RATIO
ObjectiveCBridgeFromNSArrayAnyObjectForced 6940 7900 +13.8% 0.88x (?)
 
Improvement OLD NEW DELTA RATIO
NSStringConversion.MutableCopy.Rebridge.UTF8 734 677 -7.8% 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: 8-Core Intel Xeon E5
  Processor Speed: 3 GHz
  Number of Processors: 1
  Total Number of Cores: 8
  L2 Cache (per Core): 256 KB
  L3 Cache: 25 MB
  Memory: 64 GB

@atrick atrick merged commit 96cd8fa into swiftlang:master Jan 24, 2020
@atrick atrick deleted the fix-escape-bridge branch January 29, 2020 18:05
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.

2 participants