Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Scalar replacement of enums #88628

Closed
wants to merge 2 commits into from
Closed

Scalar replacement of enums #88628

wants to merge 2 commits into from

Conversation

cjgillot
Copy link
Contributor

@cjgillot cjgillot commented Sep 3, 2021

Extension to #85796

r? @tmiasko

@bors
Copy link
Contributor

bors commented Sep 3, 2021

☔ The latest upstream changes (presumably #88572) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 3, 2021
tmiasko
tmiasko reviewed Sep 9, 2021
View reviewed changes
compiler/rustc_mir/src/transform/flatten_locals.rs
if let Some((local, discr_ty)) = self.map.discr.get(&place.local) {
let param_env_and_ty = ParamEnv::empty().and(*discr_ty);
let type_size = self.tcx.layout_of(param_env_and_ty).unwrap().size;
let scalar = Scalar::try_from_uint(variant_index.as_u32(), type_size).unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discriminant value used by specific variant can be arbitrary: discriminant_for_variant.

@tmiasko
Copy link
Contributor

tmiasko commented Sep 10, 2021

Since this transformation expands fields which originally were stored in
overlapping memory location into disjoint memory locations, is it correct only
under the assumption that enums are used in type-safe manner.

Unsafe code might violate this assumption. While the transformation validates
that the address of a local escapes, I don't think this can be consider to be a
reliable method to detect unsafe code inside optimization pipeline (since those
constructs might be optimized to a direct access).

It also inconsistent with other hypothetical transformations. For example,
consider set-discriminant of an enum using niche encoding that switches to
dataful variant. Such a set discriminant statement is a no-op (discriminant is
actually changed as a result of writing the variant data). A transformation
could remove such set-discriminants, which would be inconsistent with
transformation proposed here.

For those reasons, I think this can't run in optimization phase, but would
rather have to run in an earlier lowering phase.

It also seems to me that we should first introduce support for expansion of
variable debuginfo. Without such support this transformation is rarely applicable.
Though, I am might be missing use cases that motivated this.

@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 27, 2021
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 14, 2021
@cjgillot cjgillot closed this Oct 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tmiasko tmiasko tmiasko left review comments

Assignees
No one assigned
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@cjgillot @bors @tmiasko @JohnCSimon @apiraino