Some preliminary work towards making trans "collector driven". #33171
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @jroesch (rust_highfive has picked a reviewer for you, use r? to override) |
| @@ -52,7 +52,7 @@ impl BitVector { | |||
|
|
|||
| pub fn grow(&mut self, num_bits: usize) { | |||
| let num_words = u64s(num_bits); | |||
| let extra_words = self.data.len() - num_words; | |||
| let extra_words = (num_words as i64) - (self.data.len() as i64); | |||
There was a problem hiding this comment.
if self.data.len() < num_words { self.data.resize(num_words, 0) } instead?
Also needs a regression test.
There was a problem hiding this comment.
Yeah, that would be nicer. I'll add the test too.
michaelwoerister
force-pushed
the
collector-drop-glue
branch
from
625f97e
to
e6d3ac3
Compare
|
Changed the implementation of |
| @@ -9,7 +9,7 @@ | |||
| // except according to those terms. | |||
|
|
|||
| // ignore-tidy-linelength | |||
| // compile-flags:-Zprint-trans-items=eager | |||
| // compile-flags:-Zprint-trans-items=eager -Zincremental="" | |||
There was a problem hiding this comment.
why -Z incremental=""?
|
@bors r+ |
|
📌 Commit e6d3ac3 has been approved by |
bors
added a commit
that referenced
this pull request
Apr 27, 2016
…tsakis Some preliminary work towards making trans "collector driven". The `trans::collector` already collects all translation items and `trans::partitioning` distributes these translation items into codegen units. The changes in this PR provide the following extensions to this functionality: 1. Drop-glue is handled more accurately now, knowing about the difference between `DropGlueKind::Ty` and `DropGlueKind::TyContents`. 2. The partitioning module now supports the `FixedUnitCount` strategy which more or less corresponds to the partitioning one gets via supplying `-Ccodegen-units` today. 3. The partitioning scheme also takes care of assigned LLVM declarations to codegen units, not just definitions (declarations for external items not yet implemented). It's debatable whether declarations should be handled by the partitioning scheme or whether they should just be emitted on demand.
|
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
|
I'll take the failed test as an opportunity to address the nits. |
michaelwoerister
force-pushed
the
collector-drop-glue
branch
from
e6d3ac3
to
0fc9f9a
Compare
|
@bors r=nikomatsakis |
|
📌 Commit 0fc9f9a has been approved by |
bors
added a commit
that referenced
this pull request
Apr 28, 2016
…tsakis Some preliminary work towards making trans "collector driven". The `trans::collector` already collects all translation items and `trans::partitioning` distributes these translation items into codegen units. The changes in this PR provide the following extensions to this functionality: 1. Drop-glue is handled more accurately now, knowing about the difference between `DropGlueKind::Ty` and `DropGlueKind::TyContents`. 2. The partitioning module now supports the `FixedUnitCount` strategy which more or less corresponds to the partitioning one gets via supplying `-Ccodegen-units` today. 3. The partitioning scheme also takes care of assigned LLVM declarations to codegen units, not just definitions (declarations for external items not yet implemented). It's debatable whether declarations should be handled by the partitioning scheme or whether they should just be emitted on demand.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Oct 12, 2020
Mono collector: replace pair of ints with Range I found the initial PR (rust-lang#33171) that introduced this piece of code but I didn't find any information about why a tuple was preferred over a `Range<usize>`. I'm hoping there are no technical reasons to not do this.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Oct 12, 2020
Mono collector: replace pair of ints with Range I found the initial PR (rust-lang#33171) that introduced this piece of code but I didn't find any information about why a tuple was preferred over a `Range<usize>`. I'm hoping there are no technical reasons to not do this.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Oct 12, 2020
Mono collector: replace pair of ints with Range I found the initial PR (rust-lang#33171) that introduced this piece of code but I didn't find any information about why a tuple was preferred over a `Range<usize>`. I'm hoping there are no technical reasons to not do this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
trans::collectoralready collects all translation items andtrans::partitioningdistributes these translation items into codegen units. The changes in this PR provide the following extensions to this functionality:DropGlueKind::TyandDropGlueKind::TyContents.FixedUnitCountstrategy which more or less corresponds to the partitioning one gets via supplying-Ccodegen-unitstoday.It's debatable whether declarations should be handled by the partitioning scheme or whether they should just be emitted on demand.