@@ -62,30 +62,23 @@ namespace swift {
62
62
// / Linearized Representation of Enums
63
63
// / ----------------------------------
64
64
// /
65
- // / Since enums are sum types, our representation of enums must deal with the
66
- // / following problems:
67
- // /
68
- // / 1. An enum can require different numbers of bits in its linearized
69
- // / representation depending on the payload of the case that the enum is
70
- // / initialized to.
71
- // /
72
- // / 2. It is important that we be able to construct the exact enum case that our
73
- // / sub-element corresponds to. This implies we must in our representation store
74
- // / in some manner the actual case information. To do so, our representation
75
- // / uses 1 + log2(num enum cases) bits. The first bit shows
76
- // /
77
- // / To work around this problem in our representation, we always
78
- // / store enough bits for the max sized payload of all cases of the enum and add
79
- // / an additional set of last bits for the discriminator. Any extra bits that
80
- // / may be needed (e.x.: we are processing a enum case with a smaller payload)
81
- // / are always assumed to be set to the same value that the initial
82
- // / discriminator bit is set to.
65
+ // / Since enums are sum types, an enum can require different numbers of bits in
66
+ // / its linearized representation depending on the payload of the case that the
67
+ // / enum is initialized to. To work around this problem in our representation,
68
+ // / we always store enough bits for the max sized payload of all cases of the
69
+ // / enum and add an additional last bit for the discriminator. Any extra bits
70
+ // / that may be needed (e.x.: we are processing a enum case with a smaller
71
+ // / payload) are always assumed to be set to the same value that the
72
+ // / discriminator bit is set to. This representation allows us to track liveness
73
+ // / trading off the ability to determine information about the actual case that
74
+ // / we are tracking. Since we just care about liveness, this is a trade off that
75
+ // / we are willing to make since our goal (computing liveness) is still solved.
83
76
// /
84
77
// / With the above paragraph in mind, an example of the bit layout of an enum
85
78
// / looks as follows:
86
79
// /
87
80
// / ```
88
- // / [ PAYLOAD BITS | EXTRA_TOP_LEVEL_BITS | DISCRIMINATOR_BITS ]
81
+ // / [ PAYLOAD BITS | EXTRA_TOP_LEVEL_BITS | DISCRIMINATOR_BIT ]
89
82
// / ```
90
83
// /
91
84
// / Notice how placing the discriminator bit last ensures that separately the
0 commit comments