-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Inefficient ref counting in else if expressions #385
Comments
This problem also occurs for other types of nested blocks, so I think we should optimize the general case rather than change the representation of if/else again. |
This was mostly handled by 7d68cbd . There's still something to be gained by returning block results with move semantics, but that's not really what this bug is about. |
arielb1
pushed a commit
to arielb1/rust
that referenced
this issue
Apr 10, 2015
arielb1
pushed a commit
to arielb1/rust
that referenced
this issue
Apr 10, 2015
RFC rust-lang#385 is currently active
bors
added a commit
that referenced
this issue
Jan 29, 2016
…r=nrc We no longer require `use` and `extern crate` items to precede other items in modules thanks to [RFC #385](rust-lang/rfcs#385), but we still require `use` and `extern crate` items to precede statements in blocks (other items can appear anywhere in a block). I think that this is a needless distinction between imports and other items that contradicts the intent of the RFC.
kazcw
pushed a commit
to kazcw/rust
that referenced
this issue
Oct 23, 2018
dlrobertson
pushed a commit
to dlrobertson/rust
that referenced
this issue
Nov 29, 2018
Fix some broken links.
calebzulawski
added a commit
to calebzulawski/rust
that referenced
this issue
Feb 17, 2024
…of-u-and-me Assume masks are correct
calebzulawski
added a commit
to calebzulawski/rust
that referenced
this issue
Feb 17, 2024
Revert rust-lang#385 and add some minor fixes
calebzulawski
added a commit
to calebzulawski/rust
that referenced
this issue
Feb 17, 2024
…make-an-ass-out-of-u-and-me"" This reverts commit 644bdfb.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The way else if is currently translated the following code
translates the same as
This creates a new sub-scope for each else if branch.
The mechanism for returning results from blocks entails copying the result into a new alloca and dropping any refs for it in the parent scope. These two things combined mean that an else if chain with n else if branches will generate allocas for n results and n take/drop pairs.
I suppose it could be possible to eliminate them in an optimization pass that eliminated redundant take/drops, but this also might be a good argument for reverting to the previous, non-recursive definition of else if.
The text was updated successfully, but these errors were encountered: