Skip to content

[Inliner] Fix stack nesting when lowering OSSA. #63980

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

nate-chandler
Copy link
Contributor

Now that in OSSA partial_apply [on_stack]s are represented as owned values rather than stack locations, it is possible for their destroys to violate stack discipline. A direct lowering of the instructions to non-OSSA would violate stack nesting.

Previously, when inlining, it was assumed that non-coroutine callees maintained stack discipline. And, when inlining an OSSA function into a non-OSSA function, OSSA instructions were lowered directly. The result was that stack discipline could be violated.

Here, when inlining a function in OSSA form into a function lowered out of OSSA form, stack nesting is fixed up.

Previously, there was an -Xllvm option to verify after all inlining to a
particlar caller.  That makes it a chore to track down which apply's
inlining resulted in invalid code.  Here, a new option is added that
verifies after each run of the inliner.
Now that in OSSA `partial_apply [on_stack]`s are represented as owned
values rather than stack locations, it is possible for their destroys to
violate stack discipline.  A direct lowering of the instructions to
non-OSSA would violate stack nesting.

Previously, when inlining, it was assumed that non-coroutine callees
maintained stack discipline.  And, when inlining an OSSA function into a
non-OSSA function, OSSA instructions were lowered directly.  The result
was that stack discipline could be violated.

Here, when inlining a function in OSSA form into a function lowered out
of OSSA form, stack nesting is fixed up.
Now that in OSSA `partial_apply [on_stack]`s are represented as owned
values rather than stack locations, it is possible for their destroys to
violate stack discipline.  A direct lowering of the instructions to
non-OSSA would violate stack nesting.

Previously, when inlining, it was assumed that non-coroutine callees
maintained stack discipline.  And, when inlining an OSSA function into a
non-OSSA function, OSSA instructions were lowered directly.  The result
was that stack discipline could be violated.

Here, when inlining a function in OSSA form into a function lowered out
of OSSA form, stack nesting is fixed up.
@nate-chandler
Copy link
Contributor Author

@swift-ci please test

@nate-chandler
Copy link
Contributor Author

@swift-ci please clean test macOS platform

@meg-gupta
Copy link
Contributor

@nate-chandler CSE calls into inline helper - https://github.com/apple/swift/blob/78749d8d00e5e7fa8c82b6235a10e22c65b01098/lib/SILOptimizer/Transforms/CSE.cpp#L791 You may want to move the stack nest fixup to SILInliner::inlineFullApply

@nate-chandler
Copy link
Contributor Author

nate-chandler commented Mar 1, 2023

@meg-gupta Thanks for pointing that out. CSE will need to fixup nesting in this case. We don't want to move it into inlineFullApply because nesting shouldn't be fixed up multiple times when multiple callees are inlined. I'm adding a similar call there and also to the other call to inlineFullApply.

Copy link
Contributor

@meg-gupta meg-gupta left a comment

Choose a reason for hiding this comment

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

@nate-chandler This LGTM.

@nate-chandler
Copy link
Contributor Author

@meg-gupta The CSE fix is here: #64005 .

@nate-chandler nate-chandler merged commit dd160ce into swiftlang:main Mar 1, 2023
@nate-chandler nate-chandler deleted the inlining/partial-apply-stack-discipline branch March 1, 2023 19:50
@nate-chandler
Copy link
Contributor Author

@meg-gupta The fix for the last call to inlineFullApply is here: #64013 .

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