Skip to content

[simplify-cfg] Add a visitedBlocks set to hasSameUltimateSuccessor to prevent infinite loops. #27449

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

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented Oct 1, 2019

Previously, we were not handling properly blocks that we could visit multiple
times. In this commit, I added a SmallPtrSet to ensure that we handle all of the
same cases that we handled previously.

The key reason that we want to follow this approach rather than something else
is that the previous algorithm on purpose allowed for side-entrances from other
checks since often times when we have multiple checks, all of the .none branches
funnel together into a single ultimate block.

This can be seen by the need of this code to support the test two_chained_calls
in simplify_switch_enum_objc.sil.

rdar://55861081

…nches for testing purposes

I am going to use this in a subsequent commit to make sure we do not infinite
loop upon a test case.

rdar://55861081
… prevent infinite loops.

Previously, we were not handling properly blocks that we could visit multiple
times. In this commit, I added a SmallPtrSet to ensure that we handle all of the
same cases that we handled previously.

The key reason that we want to follow this approach rather than something else
is that the previous algorithm on purpose allowed for side-entrances from other
checks since often times when we have multiple checks, all of the .none branches
funnel together into a single ultimate block.

This can be seen by the need of this code to support the test two_chained_calls
in simplify_switch_enum_objc.sil.

rdar://55861081
@gottesmm gottesmm requested a review from eeckstein October 1, 2019 00:04
@gottesmm
Copy link
Contributor Author

gottesmm commented Oct 1, 2019

@swift-ci test

@gottesmm
Copy link
Contributor Author

gottesmm commented Oct 1, 2019

@swift-ci benchmark

@swift-ci
Copy link
Contributor

swift-ci commented Oct 1, 2019

Performance: -O

Regression OLD NEW DELTA RATIO
DataAppendDataSmallToSmall 2760 3200 +15.9% 0.86x (?)
 
Improvement OLD NEW DELTA RATIO
FlattenListFlatMap 4902 4573 -6.7% 1.07x (?)

Code size: -O

Performance: -Osize

Code size: -Osize

Performance: -Onone

Regression OLD NEW DELTA RATIO
DataAppendDataSmallToSmall 2820 3240 +14.9% 0.87x (?)

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 mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

Copy link
Contributor

@eeckstein eeckstein left a comment

Choose a reason for hiding this comment

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

lgtm!

@gottesmm gottesmm merged commit 1a1f731 into swiftlang:master Oct 1, 2019
@gottesmm gottesmm deleted the pr-65212fe82c5dfab8b4f1b86bdd9f513ecc63393c branch October 1, 2019 19:17
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