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.

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

Closed
brson opened this issue May 18, 2011 · 2 comments
Closed

Inefficient ref counting in else if expressions #385

brson opened this issue May 18, 2011 · 2 comments

Comments

@brson
Copy link
Contributor

brson commented May 18, 2011

The way else if is currently translated the following code

auto x = if (a) {
  b
} else if (c) {
  d
} else {
  e
};

translates the same as

auto x = if (a) {
  b
} else {
  if (c) {
    d
  } else {
    e
  }
};

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.

@marijnh
Copy link
Contributor

marijnh commented May 18, 2011

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.

@marijnh
Copy link
Contributor

marijnh commented Jun 16, 2011

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.

@marijnh marijnh closed this as completed Jun 16, 2011
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
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
calebzulawski added a commit to calebzulawski/rust that referenced this issue Feb 17, 2024
calebzulawski added a commit to calebzulawski/rust that referenced this issue Feb 17, 2024
…ass-out-of-u-and-me"

This reverts commit 6ad779c, reversing
changes made to b2e1bcb.
calebzulawski added a commit to calebzulawski/rust that referenced this issue Feb 17, 2024
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants