Skip to content

Commit 33b83e2

Browse files
committed
Don't split up stores into an existential payload in DI
Predictable memory optimization would do the wrong thing upon encountering a copy_addr into the payload of an existential -- if the source of the copy was otherwise promotable, it would attempt to explode the copy_addr into a sequence of scalars. The 'sub-element' counting code assumed that the source and destination type had the same shape when tuples and structs were exploded, so if the existential payload was a struct or tuple with multiple elements, invariants would be lost in the bookkeeping code. So it appears that if the destination of a store is an existential payload it does not really make sense to consider the uses individually in DI. I'm not aware of any code that SILGen currently emits which may trigger this, but it came up while I was testing some other stuff.
1 parent 9ccc2dd commit 33b83e2

File tree

1 file changed

+2
-8
lines changed

1 file changed

+2
-8
lines changed

lib/SILPasses/EarlySIL/DIMemoryUseCollector.cpp

Lines changed: 2 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -749,22 +749,16 @@ void ElementUseCollector::collectUses(SILValue Pointer, unsigned BaseEltNo) {
749749
continue;
750750
}
751751

752-
// init_existential_addr is modeled as an initialization store, where the
753-
// uses are treated as subelement accesses.
752+
// init_existential_addr is modeled as an initialization store.
754753
if (isa<InitExistentialAddrInst>(User)) {
755754
assert(!InStructSubElement &&
756755
"init_existential_addr should not apply to struct subelements");
757756
Uses.push_back(DIMemoryUse(User, DIUseKind::Initialization,
758757
BaseEltNo, 1));
759-
760-
// Set the "InEnumSubElement" flag (so we don't consider tuple indexes to
761-
// index across elements) and recursively process the uses.
762-
llvm::SaveAndRestore<bool> X(InEnumSubElement, true);
763-
collectUses(SILValue(User, 0), BaseEltNo);
764758
continue;
765759
}
766760

767-
// inject_enum_addr is treated as a store unconditionally.
761+
// inject_enum_addr is modeled as an initialization store.
768762
if (isa<InjectEnumAddrInst>(User)) {
769763
assert(!InStructSubElement &&
770764
"inject_enum_addr the subelement of a struct unless in a ctor");

0 commit comments

Comments
 (0)