-
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
Niche placement heuristic: place at beginning or end of type #104807
Comments
Besides the type-size #102750 also added a secondary sort key to move the field with the largest niche in a alignment-group to the end of a alignment-group to not break a test-case introduced by #94075 which is an optimization that benefits from having niches towards the end. So within Maybe the sort can be made more sophisticated to only try to move things towards the end when there already is another discriminant in the beginning. Or maybe we can add the information where it's located to the niche data. |
I think it would be necessary for the secondary sort to consider where the niche is located inside each field type. #94075 benefits when the largest niche gets placed as far from the middle of the type as possible. By just looking at which field has the largest niche, your PR ended up placing the niche in |
"Middle" and "End" (i.e. the relative placement) doesn't really matter. What matters it's far enough back that it's further than shorter enum variants in the outer enum. If the variant lengths are sufficiently different then even moving it back a little will help, it doesn't need to be at the absolute end. I don't think any heuristics will be optimal in all cases. But maybe there's room for improvement for some subset. |
This is not accurate as far as I can tell. For example see playground in which This is reinforced by the description of #46213 as well: "As long as The relevant thing is that the niche goes as far from the middle of the type as possible (my suggestion), so that the largest possible other type can line up "before or after" the niche.
We should not be moving niches back if that means moving them toward the middle of the type, because that ends up being a worse placement. In fact if there's a niche in the first half of a field's type, we should typically be trying to place that field as far forward as possible, not back. |
**Description** Add a check for the `nightly` feature flag to change the expected sizes in different tests. This seems like a short-term solution because the nightly changes will eventually get promoted to stable and then this change will need to be removed. I found a possibly related [rust-lang issue #104807][rust-issue-104807] , maybe the fix for this will change the nightly enum sizes back to their previous values **Motivation** CI was breaking on the nightly and miri tests **Testing Done** - `cargo +nightly test --features nightly` passes - `cargo +nightly miri test` passes - `cargo +nightly test` fails [rust-issue-104807]: rust-lang/rust#104807
I noticed that #102750 regressed the size of some types in the
syn
crate. I minimized the difference to the following:The type layout in nightly-2022-11-23 is:
and in nightly-2022-11-24:
Graphically, the layout of Enum::A and Enum::B before and after are:
Notice how the old layout is putting
Thing
at the beginning ofA
andB
, while the new layout is puttingThing
at the end ofA
andB
. The reason the new layout is worse is that now, when buildingEnum
, there is no way to line upA
's existing niche with theB
case's padding. Instead a whole new discriminant needs to be added.From reading the description of #102750, I don't get the impression that the justification of that PR applies to the difference in this placement of
Thing
insideA
andB
in the code above. It seems like just a coincidence of the implementation that the PR affected this code.My observation is that, other things being equal, we should prefer to locate niches
in the very beginning or very end of a type, not in the middlenear the beginning or end of a type, as far from the middle of the type as possible. This will allow them to get lined up with the padding of smaller enum variants. Placing a niche as far from the middle of the type as possible makes room for the largest possible other type to line up before or after the niche.Mentioning @the8472 @wesleywiser since you were recently working on layout.
The text was updated successfully, but these errors were encountered: