Uh oh!
There was an error while loading. Please reload this page.
Some preliminary work towards making trans "collector driven". - #33171
Merged
Conversation
rust-highfive
commented
Apr 23, 2016
Contributor
r? @jroesch (rust_highfive has picked a reviewer for you, use r? to override) |
michaelwoerister
commented
Apr 23, 2016
MemberAuthor
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.
MemberAuthor
There was a problem hiding this comment.
Yeah, that would be nicer. I'll add the test too.
michaelwoeristerforce-pushed
the
collector-drop-glue
branch
from
April 26, 2016 19:20
625f97e to
e6d3ac3Comparemichaelwoerister
commented
Apr 26, 2016
MemberAuthor
Changed the implementation of |
nikomatsakis
commented
Apr 26, 2016
Contributor
| // ignore-tidy-linelength | ||
| // compile-flags:-Zprint-trans-items=eager | ||
| // compile-flags:-Zprint-trans-items=eager -Zincremental="" |
nikomatsakis
commented
Apr 27, 2016
Contributor
@bors r+ |
bors
commented
Apr 27, 2016
Collaborator
📌 Commit e6d3ac3 has been approved by |
bors
commented
Apr 27, 2016
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.
bors
commented
Apr 27, 2016
Collaborator
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
michaelwoerister
commented
Apr 27, 2016
MemberAuthor
I'll take the failed test as an opportunity to address the nits. |
michaelwoeristerforce-pushed
the
collector-drop-glue
branch
from
April 28, 2016 20:53
e6d3ac3 to
0fc9f9aComparemichaelwoerister
commented
Apr 28, 2016
MemberAuthor
@bors r=nikomatsakis |
bors
commented
Apr 28, 2016
Collaborator
📌 Commit 0fc9f9a has been approved by |
bors
commented
Apr 28, 2016
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.
bors
commented
Apr 28, 2016
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 freeto 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.