[opt] Re-work broadenSingleElementStores to use projections.

[zoecarver]

• Fixes loadable edge case for address-only types.
• Re-work, generalize, and simplify by using projections.
• Support -enable-cxx-interop in sil-opt.

Refs #32291.

[zoecarver]

@atrick what do you think about supporting opaque types here?

[atrick]

What cases are you trying to handle by doing that? Can you find out if it's possible to have
baseAddrType.isLoadable(*f) == true
AND
baseAddrType.aggregateHasUnreferenceableStorage() == false
??

[zoecarver]

Do you mean baseAddrType.isLoadable(*f) && baseAddrType.aggregateHasUnreferenceableStorage() == true? If not, I think that's most loadable types.

I think if we have a trivial struct with a bitfield that would do it: struct Foo { int x : 3; };. That struct will be loadable (even though, maybe it shouldn't be) but will also have un-referenceable storage (x).

[atrick]

ok, so what case are you trying to handle? A struct with a single opaque property? So that "store" would need to actually be a copy_addr?

[gottesmm]

@atrick my understanding is that has unreferencable storage is for things from c/c++ that have memory/other things that are not exposed to swift. To me it is sort of like an early, hacky resilience-esque sort of thing.

[zoecarver]

what case are you trying to handle?

I'm not trying to handle any particular case. Currently, we will bail on opaque types. I just wanted to make sure that's the correct behavior.

To me it is sort of like an early, hacky resilience-esque sort of thing.

I think this is true, yes. But most non-loadable types are non-loadable for ABI reasons, or to make sure calling conventions work with the C++ definitions.

[atrick]

isLoadable seems like a sensible bailout considering we're dealing with storing values at its address

[atrick]

I don't want to say that I carefully reviewed this or thought about alternatives, but the implementation looks reasonable to me.

[gottesmm]

Some quick comments. I am fine with this landing after you fix the few nits and we finish answering Andy's questions.

[gottesmm]

@atrick my understanding is that has unreferencable storage is for things from c/c++ that have memory/other things that are not exposed to swift. To me it is sort of like an early, hacky resilience-esque sort of thing.

[zoecarver]

@gottesmm thanks for the review. I addressed all your comments.

[zoecarver]

@swift-ci please smoke test

[zoecarver]

@swift-ci please smoke test.

[zoecarver]

@swift-ci please test windows platform.

[gottesmm]

@zoecarver Can you change the name of this file to something more meaningful? I didn't notice the name when I was reviewing.