|
|
| Previous ID |
SR-3726 |
| Radar |
rdar://problem/34141063 |
| Original Reporter |
@ematejska |
| Type |
Task |
| Status |
Resolved |
| Resolution |
Won't Do |
Additional Detail from JIRA
|
|
| Votes |
0 |
| Component/s |
|
| Labels |
Task, AffectsABI |
| Assignee |
None |
| Priority |
Medium |
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.
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.