Skip to content

[4.2-04-30-2018][pred-memopts] Rather than asserting on recursive initialization, jus… #16545

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

…t return false and bail.

Until the beginning of the ownership transition, DI and predictable mem opts
used the same memory use collector. I split them partially since I need to turn
on ownership for predictable mem opts at one time, but also b/c there was a huge
amount of special code that would only trigger if it was used by DI or used by
predictable mem opts. After I did the copy some of the asserts that were needed
for DI remained in the predictable mem opts code. When pred-memopts was only run
in the mandatory pipeline keeping these assertions were ok, but pred-memopts was
recently added to the perf pipeline meaning that it may see code that breaks
these DI invariants (and thus hit this assertion).

We should remove this limitation on predictable-memopts but that would require
some scheduled time to read the code (more than I have to fix this bug = p). So
instead I changed the code to just bail in these cases.

rdar://40032102
(cherry picked from commit 269f8e8)

…t return false and bail.

Until the beginning of the ownership transition, DI and predictable mem opts
used the same memory use collector. I split them partially since I need to turn
on ownership for predictable mem opts at one time, but also b/c there was a huge
amount of special code that would only trigger if it was used by DI or used by
predictable mem opts. After I did the copy some of the asserts that were needed
for DI remained in the predictable mem opts code. When pred-memopts was only run
in the mandatory pipeline keeping these assertions were ok, but pred-memopts was
recently added to the perf pipeline meaning that it may see code that breaks
these DI invariants (and thus hit this assertion).

We should remove this limitation on predictable-memopts but that would require
some scheduled time to read the code (more than I have to fix this bug = p). So
instead I changed the code to just bail in these cases.

rdar://40032102
(cherry picked from commit 269f8e8)
@gottesmm
Copy link
Contributor Author

@swift-ci test

@gottesmm gottesmm changed the title [pred-memopts] Rather than asserting on recursive initialization, jus… [4.2-04-30-2018][pred-memopts] Rather than asserting on recursive initialization, jus… May 11, 2018
%4 = load %0 : $*SWithOpt
dealloc_stack %0 : $*SWithOpt
return %4 : $SWithOpt
}

Choose a reason for hiding this comment

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

No new line at end of file

Copy link

@shajrawi shajrawi left a comment

Choose a reason for hiding this comment

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

LGTM! please add a new line at the end of file for the test case

@gottesmm
Copy link
Contributor Author

@shajrawi Joe, since this that doesn't affect anything, I am going to first go through CCC without the newline and then after it gets through CCC add the newline and do a smoke test. I want to make sure that CCC approval sees that this passes the full tests.

@gottesmm
Copy link
Contributor Author

Explanation: Eliminates a DI specific assert that pred-memopts could hit. This assert was a vestigal remnant in pred-memopts from when DI and pred-memopts shared common utility code. We did not hit it before since we only used to run pred-memopts right after DI (implying the invariants would still be true). We are now running it in the perf pipeline as well where these invariants are no longer true. Rather than assert or have pred-memopts handle these new untested cases, we are instead conservative in this PR and just bail.
Scope: This makes the code more conservative and reduces risk by ensuring that we do not go down this untested code path in a non-asserts build.
Radar/SR Issue: rdar://40032102
Risk: Low risk. This just causes the optimizer to not handle these specific cases.
Testing: Compiler regression tests.
Reviewer: @shajrawi

@gottesmm
Copy link
Contributor Author

@swift-ci please nominate

gottesmm added a commit to gottesmm/swift that referenced this pull request May 11, 2018
@gottesmm
Copy link
Contributor Author

Approved by Ted via email. I am think it makes more sense to just merge this now and just add the newline on master.

@gottesmm gottesmm merged commit b9e98b5 into swiftlang:swift-4.2-branch-04-30-2018 May 11, 2018
@gottesmm gottesmm deleted the swift-4.2-branch-04-30-2018-rdar40032102 branch May 11, 2018 22:01
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