Skip to content

Conversation

eeckstein
Copy link
Contributor

Even if a destroy_addr of a trivial type is a no-op, we must not end up with using such a value after a destroy_addr.
The fix is to also handle aggregate fields of trivial types in MemoryLifetime.

rdar://problem/55125020

…ddr before a use of a trivial type.

Even if a destroy_addr of a trivial type is a no-op, we must not end up with using such a value after a destroy_addr.
The fix is to also handle aggregate fields of trivial types in MemoryLifetime.

rdar://problem/55125020
@eeckstein eeckstein requested a review from atrick September 11, 2019 11:51
@eeckstein
Copy link
Contributor Author

@swift-ci test

@eeckstein eeckstein merged commit df0ed6b into swiftlang:master Sep 11, 2019
@eeckstein eeckstein deleted the fix-memory-lifetime branch September 11, 2019 14:24
Copy link
Contributor

@atrick atrick left a comment

Choose a reason for hiding this comment

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

Generally looks good.

@@ -73,6 +73,17 @@ static bool allUsesInSameBlock(AllocStackInst *ASI) {
return numDeallocStacks == 1;
}

static bool shouldTrackLocation(SILType ty, SILFunction *function) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you anticipate using function eventually?

// case of enums, e.g. store of Optional.none to an Optional<T> where T
// is not trivial.
// In such a case it can happen that the Optional<T> is not destoyed.
// We currently cannot handle such patterns.
Copy link
Contributor

Choose a reason for hiding this comment

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

This code checks for storing a nontrivial type into a trivial memory location. The comments seem to say the opposite. Is that a mistake or my misunderstanding? Can you add a unit test for this special case (and the inverse case if that's also a problem)? I don't understand why this needs to be a bailout rather than just tracking this location as trivial so the full nontrivial constraints aren't applied.

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