You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ahead of ABI stability, consider if tuple elements are bit-packed to save space.
Updated
This issue should track the overall data layout for tuples. Here is the relevant text from the ABI manifesto:
Tuples are similar to anonymous structs, but they differ in that they exhibit structural subtyping: a tuple of type e.g. (Bool, Bool) can be passed anywhere expecting generic types (T, U). But, the type (T, U) exists at a higher abstraction level than (Bool, Bool). Due to this, tuples may face more expensive reabstraction costs if their layout is aggressively packed. Reabstracting such a tuple would involve splitting and promoting each element into their own addresses.
This may be an argument for a simple, declaration-order, non bit-packed layout algorithm for tuples. Tuples are often used for small local values and rarely persisted across ABI boundaries in a way that aggressive packing is performance-critical. This would also be more consistent with how fixed-size C arrays are presented in Swift, which are imported as tuples.
We should investigate whether to aggressively bit-pack tuple elements similarly to structs, paying the reabstraction costs, or if the benefits are not worth the costs [SR-3726].
Tuples should be binary compatible between labeled and unlabeled tuples of the same type and structure.
The text was updated successfully, but these errors were encountered:
We've previously promised that homogeneous tuples of C types will have C layout, so we can't bitpack (Bool, Bool, Bool). @rjmccall has been inclined to extend that to just make tuples use C layout all the time, but I don't know if we've formally promised that yet.
OK, so we can't bit pack tuples and do not plan any other changes for tuple layout in Swift 5. The only thing left is to document the layout algorithm and we can track that in SR-3730
Additional Detail from JIRA
md5: 49f72855cd0ebf30564d52987c7d03f6
Issue Description:
Ahead of ABI stability, consider if tuple elements are bit-packed to save space.
Updated
This issue should track the overall data layout for tuples. Here is the relevant text from the ABI manifesto:
Tuples are similar to anonymous structs, but they differ in that they exhibit structural subtyping: a tuple of type e.g.
(Bool, Bool)
can be passed anywhere expecting generic types(T, U)
. But, the type(T, U)
exists at a higher abstraction level than(Bool, Bool)
. Due to this, tuples may face more expensive reabstraction costs if their layout is aggressively packed. Reabstracting such a tuple would involve splitting and promoting each element into their own addresses.This may be an argument for a simple, declaration-order, non bit-packed layout algorithm for tuples. Tuples are often used for small local values and rarely persisted across ABI boundaries in a way that aggressive packing is performance-critical. This would also be more consistent with how fixed-size C arrays are presented in Swift, which are imported as tuples.
We should investigate whether to aggressively bit-pack tuple elements similarly to structs, paying the reabstraction costs, or if the benefits are not worth the costs [SR-3726].
Tuples should be binary compatible between labeled and unlabeled tuples of the same type and structure.
The text was updated successfully, but these errors were encountered: