Skip to content

Enable ArrayElementValuePropagation on ownership SIL #34549

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
Nov 4, 2020

Conversation

meg-gupta
Copy link
Contributor

No description provided.

@meg-gupta
Copy link
Contributor Author

@swift-ci test

@swift-ci
Copy link
Contributor

swift-ci commented Nov 3, 2020

Build failed
Swift Test Linux Platform
Git Sha - a24b2327499a517229d2fdebabb946e7be3ba340

return std::next(cast<SingleValueInstruction>(val)->getIterator());
}
if (isa<SILArgument>(val)) {
return cast<SILArgument>(val)->getParentBlock()->begin();
Copy link
Contributor

Choose a reason for hiding this comment

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

This is just a quick drive by, but there is an API that already supports this: getDefiningInsertionPt.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmmm... I see why this is a little different.

// Because we are creating copy_value in ossa, and the source may have been
// taken previously. So our insert point for copy_value is immediately after
// V, where we can be sure it is live.
auto InsertPt = V->getFunction()->hasOwnership()
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not just this to always do this? Then we have one implementation? I haven't thought through it maybe there is a reason not to.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could, but the retain would be much earlier than when we need, and I was thinking it may effect arc optimizations.

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!
I just have 2 minor comments.

@@ -105,7 +105,6 @@ struct SemanticARCOpts : SILFunctionTransform {
if (!f.getModule().getOptions().EnableOSSAOptimizations ||
!f.hasOwnership())
return;

Copy link
Contributor

Choose a reason for hiding this comment

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

Is this deleted empty line intention?

SILValue CopiedVal =
SILBuilderWithScope(InsertPt.getValue())
.emitCopyValueOperation(SemanticsCall->getLoc(), V);
SemanticsCall->replaceAllUsesWith(CopiedVal);
} else {
auto Dest = SemanticsCall->getArgument(0);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you can remove this else-branch completely. It stems from a time where the specializations of getElement did return an indirect result, even for loadable types. This should not be the case anymore. You can just bail if !hasGetElementDirectResult().

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed this.

@meg-gupta
Copy link
Contributor Author

@swift-ci smoke test and merge

@swift-ci swift-ci merged commit a7ca167 into swiftlang:main Nov 4, 2020
@meg-gupta meg-gupta deleted the arrayelempropossa branch July 9, 2021 00:27
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.

4 participants