swift234

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.