Some preliminary work towards making trans "collector driven".#33171
Merged
bors merged 3 commits intorust-lang:masterfrom Apr 28, 2016
Merged
Some preliminary work towards making trans "collector driven".#33171bors merged 3 commits intorust-lang:masterfrom
bors merged 3 commits intorust-lang:masterfrom
Conversation
Contributor
|
r? @jroesch (rust_highfive has picked a reviewer for you, use r? to override) |
Member
Author
Member
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.
Member
Author
There was a problem hiding this comment.
Yeah, that would be nicer. I'll add the test too.
625f97e to
e6d3ac3
Compare
Member
Author
|
Changed the implementation of |
Contributor
|
|
||
| // ignore-tidy-linelength | ||
| // compile-flags:-Zprint-trans-items=eager | ||
| // compile-flags:-Zprint-trans-items=eager -Zincremental="" |
Contributor
There was a problem hiding this comment.
why -Z incremental=""?
Contributor
|
@bors r+ |
Collaborator
|
📌 Commit e6d3ac3 has been approved by |
Collaborator
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.
Collaborator
|
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
Member
Author
|
I'll take the failed test as an opportunity to address the nits. |
e6d3ac3 to
0fc9f9a
Compare
Member
Author
|
@bors r=nikomatsakis |
Collaborator
|
📌 Commit 0fc9f9a has been approved by |
Collaborator
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.
Collaborator
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.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.