-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Space-optimize Option<T>
for integral enum T
#14540
Comments
I whipped up a dummy example to see how this would optimize |
I don't want to comment too much on what should be the language defined method of determining the one "invalid" bit pattern that would get chosen among all the possible ones. But I do believe that if at least one "invalid" bit pattern (interpreted as the underlying integral type of the enum) exists such that it is either larger than the largest enum variant or smaller than the smallest enum variant, then one of those should be guaranteed to get chosen. This enables users to create C-like enums that they use as integers bounded to a certain continuous range of values (by providing their own unsafe iterators for such an enum type). For example, given the following enum:
The language should guarantee that the "invalid" bit pattern used for representing the [Edit] |
Don't you think it could be done transitively for all tagged unions and integral enum types? I have three optimizations on my mind:
I think the bit pattern of a variant should should be as close to 0 as possible in the order of declaration, just like in integral enums. It could stay undefined or become implementation defined |
Why wouldn't this be the default? (That is, why would all optimisations be applied by default.) |
I don't really understand the question. I'm sure that there are plenty of other possible optimizations, but they can be implemented irrespective of this proposed optimization and I think they should get their own dedicated github-issues. This proposed optimization should happen automatically, just like the non-null based space-optimization of |
@huonw, because it's a space-time tradeoff. Ideally, all possible values of an ADT could be represented within a minimal number of bits. However, values can be moved out of enums, so they should exist somewhere with proper alignment. Matching complex packed enums could still get expensive without simple discriminants: enum Value {
A = 20,
B = 21,
}
// Option<Result<Value, IoErrorKind>>
match maybe_result {
// matches on {22, _}
None => a,
// matches on {18, 0}
Some(Err(ShortWrite(0))) => b,
// matches on {x, _} if 20 <= x && x < 22
Some(Ok(_)) => c,
} |
@pczarn But there is no space-time tradeoff with the space-optimization that is being proposed here. |
Of course, sorry, I was referring to something else. |
Triage: no changes I'm aware of. |
I'm going to close this in favor of rust-lang/rfcs#1230 since there's a lot of potential layout optimizations involving enums but this one specific issue isn't key enough that it should be tracked separately. |
Refactor type memory layouts and ABIs, to be more general and easier to optimize. To combat combinatorial explosion, type layouts are now described through 3 orthogonal properties: * `Variants` describes the plurality of sum types (where applicable) * `Single` is for one inhabited/active variant, including all C `struct`s and `union`s * `Tagged` has its variants discriminated by an integer tag, including C `enum`s * `NicheFilling` uses otherwise-invalid values ("niches") for all but one of its inhabited variants * `FieldPlacement` describes the number and memory offsets of fields (if any) * `Union` has all its fields at offset `0` * `Array` has offsets that are a multiple of its `stride`; guarantees all fields have one type * `Arbitrary` records all the field offsets, which can be out-of-order * `Abi` describes how values of the type should be passed around, including for FFI * `Uninhabited` corresponds to no values, associated with unreachable control-flow * `Scalar` is ABI-identical to its only integer/floating-point/pointer "scalar component" * `ScalarPair` has two "scalar components", but only applies to the Rust ABI * `Vector` is for SIMD vectors, typically `#[repr(simd)]` `struct`s in Rust * `Aggregate` has arbitrary contents, including all non-transparent C `struct`s and `union`s Size optimizations implemented so far: * ignoring uninhabited variants (i.e. containing uninhabited fields), e.g.: * `Option<!>` is 0 bytes * `Result<T, !>` has the same size as `T` * using arbitrary niches, not just `0`, to represent a data-less variant, e.g.: * `Option<bool>`, `Option<Option<bool>>`, `Option<Ordering>` are all 1 byte * `Option<char>` is 4 bytes * using a range of niches to represent *multiple* data-less variants, e.g.: * `enum E { A(bool), B, C, D }` is 1 byte Code generation now takes advantage of `Scalar` and `ScalarPair` to, in more cases, pass around scalar components as immediates instead of indirectly, through pointers into temporary memory, while avoiding LLVM's "first-class aggregates", and there's more untapped potential here. Closes #44426, fixes #5977, fixes #14540, fixes #43278.
Refactor type memory layouts and ABIs, to be more general and easier to optimize. To combat combinatorial explosion, type layouts are now described through 3 orthogonal properties: * `Variants` describes the plurality of sum types (where applicable) * `Single` is for one inhabited/active variant, including all C `struct`s and `union`s * `Tagged` has its variants discriminated by an integer tag, including C `enum`s * `NicheFilling` uses otherwise-invalid values ("niches") for all but one of its inhabited variants * `FieldPlacement` describes the number and memory offsets of fields (if any) * `Union` has all its fields at offset `0` * `Array` has offsets that are a multiple of its `stride`; guarantees all fields have one type * `Arbitrary` records all the field offsets, which can be out-of-order * `Abi` describes how values of the type should be passed around, including for FFI * `Uninhabited` corresponds to no values, associated with unreachable control-flow * `Scalar` is ABI-identical to its only integer/floating-point/pointer "scalar component" * `ScalarPair` has two "scalar components", but only applies to the Rust ABI * `Vector` is for SIMD vectors, typically `#[repr(simd)]` `struct`s in Rust * `Aggregate` has arbitrary contents, including all non-transparent C `struct`s and `union`s Size optimizations implemented so far: * ignoring uninhabited variants (i.e. containing uninhabited fields), e.g.: * `Option<!>` is 0 bytes * `Result<T, !>` has the same size as `T` * using arbitrary niches, not just `0`, to represent a data-less variant, e.g.: * `Option<bool>`, `Option<Option<bool>>`, `Option<Ordering>` are all 1 byte * `Option<char>` is 4 bytes * using a range of niches to represent *multiple* data-less variants, e.g.: * `enum E { A(bool), B, C, D }` is 1 byte Code generation now takes advantage of `Scalar` and `ScalarPair` to, in more cases, pass around scalar components as immediates instead of indirectly, through pointers into temporary memory, while avoiding LLVM's "first-class aggregates", and there's more untapped potential here. Closes #44426, fixes #5977, fixes #14540, fixes #43278.
Refactor type memory layouts and ABIs, to be more general and easier to optimize. To combat combinatorial explosion, type layouts are now described through 3 orthogonal properties: * `Variants` describes the plurality of sum types (where applicable) * `Single` is for one inhabited/active variant, including all C `struct`s and `union`s * `Tagged` has its variants discriminated by an integer tag, including C `enum`s * `NicheFilling` uses otherwise-invalid values ("niches") for all but one of its inhabited variants * `FieldPlacement` describes the number and memory offsets of fields (if any) * `Union` has all its fields at offset `0` * `Array` has offsets that are a multiple of its `stride`; guarantees all fields have one type * `Arbitrary` records all the field offsets, which can be out-of-order * `Abi` describes how values of the type should be passed around, including for FFI * `Uninhabited` corresponds to no values, associated with unreachable control-flow * `Scalar` is ABI-identical to its only integer/floating-point/pointer "scalar component" * `ScalarPair` has two "scalar components", but only applies to the Rust ABI * `Vector` is for SIMD vectors, typically `#[repr(simd)]` `struct`s in Rust * `Aggregate` has arbitrary contents, including all non-transparent C `struct`s and `union`s Size optimizations implemented so far: * ignoring uninhabited variants (i.e. containing uninhabited fields), e.g.: * `Option<!>` is 0 bytes * `Result<T, !>` has the same size as `T` * using arbitrary niches, not just `0`, to represent a data-less variant, e.g.: * `Option<bool>`, `Option<Option<bool>>`, `Option<Ordering>` are all 1 byte * `Option<char>` is 4 bytes * using a range of niches to represent *multiple* data-less variants, e.g.: * `enum E { A(bool), B, C, D }` is 1 byte Code generation now takes advantage of `Scalar` and `ScalarPair` to, in more cases, pass around scalar components as immediates instead of indirectly, through pointers into temporary memory, while avoiding LLVM's "first-class aggregates", and there's more untapped potential here. Closes #44426, fixes #5977, fixes #14540, fixes #43278.
Refactor type memory layouts and ABIs, to be more general and easier to optimize. To combat combinatorial explosion, type layouts are now described through 3 orthogonal properties: * `Variants` describes the plurality of sum types (where applicable) * `Single` is for one inhabited/active variant, including all C `struct`s and `union`s * `Tagged` has its variants discriminated by an integer tag, including C `enum`s * `NicheFilling` uses otherwise-invalid values ("niches") for all but one of its inhabited variants * `FieldPlacement` describes the number and memory offsets of fields (if any) * `Union` has all its fields at offset `0` * `Array` has offsets that are a multiple of its `stride`; guarantees all fields have one type * `Arbitrary` records all the field offsets, which can be out-of-order * `Abi` describes how values of the type should be passed around, including for FFI * `Uninhabited` corresponds to no values, associated with unreachable control-flow * `Scalar` is ABI-identical to its only integer/floating-point/pointer "scalar component" * `ScalarPair` has two "scalar components", but only applies to the Rust ABI * `Vector` is for SIMD vectors, typically `#[repr(simd)]` `struct`s in Rust * `Aggregate` has arbitrary contents, including all non-transparent C `struct`s and `union`s Size optimizations implemented so far: * ignoring uninhabited variants (i.e. containing uninhabited fields), e.g.: * `Option<!>` is 0 bytes * `Result<T, !>` has the same size as `T` * using arbitrary niches, not just `0`, to represent a data-less variant, e.g.: * `Option<bool>`, `Option<Option<bool>>`, `Option<Ordering>` are all 1 byte * `Option<char>` is 4 bytes * using a range of niches to represent *multiple* data-less variants, e.g.: * `enum E { A(bool), B, C, D }` is 1 byte Code generation now takes advantage of `Scalar` and `ScalarPair` to, in more cases, pass around scalar components as immediates instead of indirectly, through pointers into temporary memory, while avoiding LLVM's "first-class aggregates", and there's more untapped potential here. Closes #44426, fixes #5977, fixes #14540, fixes #43278.
…gle_brace, r=Veykril Fix allow extracting function from single brace of block expression Fix allow extracting function when selecting either `{` or `}` Fix rust-lang#14514
_Summary_
I propose a space optimization for variables of type
Option<E>
whenE
is a nullary, integral enum type._Motivation_
There's no need to waste memory for storing a separate tag in variables of type
Option<E>
ifE
is an integral enum type and the set of valid values ofE
does not cover all possible bit patterns. Any bit pattern (of the size ofE
) that doesn't represent a valid value of typeE
could be used by the compiler to represent theNone
value of typeOption<E>
._Details_
Given a nullary, integral enum type
E
, the compiler should check if some bit pattern exists which does not represent a valid value of typeE
(the only valid values are the ones determined by the nullary enum variants ofE
). If such "invalid" bit patterns are found, the compiler should use one of them to represent theNone
value of typeOption<E>
and omit storing the tag in variables of typeOption<E>
. If more than one such "invalid" bit pattern exists, there should be a language defined method to deterministically determine which one of those bit patterns is used to represent theNone
value. I think the bit pattern ofNone
should be language defined rather than implementation defined in order to makeOption<E>
values serialized to disk more stable between different compilers / compiler versions.In determining whether a certain value of such space optimized type
Option<E>
isNone
or not, the algorithm should simply check whether or not the binary representation of said value is equal to the binary representation of the language defined "invalid" value.The text was updated successfully, but these errors were encountered: