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

rustc: Implement incremental "fat" LTO #58378

Merged
merged 1 commit into from Feb 14, 2019

Conversation

Projects
None yet
5 participants
@alexcrichton
Copy link
Member

alexcrichton commented Feb 11, 2019

Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!

This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.

cc #57968
cc rust-lang/cargo#6643

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Feb 11, 2019

r? @zackmdavis

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton

This comment has been minimized.

Copy link
Member Author

alexcrichton commented Feb 11, 2019

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 12, 2019

☔️ The latest upstream changes (presumably #58389) made this pull request unmergeable. Please resolve the merge conflicts.

rustc: Implement incremental "fat" LTO
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!

This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.

cc #57968
cc rust-lang/cargo#6643

@alexcrichton alexcrichton force-pushed the alexcrichton:incremental-lto branch from bc41ea8 to e983b4f Feb 12, 2019

@alexcrichton alexcrichton referenced this pull request Feb 12, 2019

Merged

Fill out examples #16

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Feb 12, 2019

I skimmed through this, looks good! I'll be able to do a proper review tomorrow hopefully.

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Feb 13, 2019

Thanks, @alexcrichton! Looks great! But wow has this code become complicated. I think the whole backend is up for a re-write once a thread-safe tcx is in place...

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 13, 2019

📌 Commit e983b4f has been approved by michaelwoerister

Centril added a commit to Centril/rust that referenced this pull request Feb 14, 2019

Rollup merge of rust-lang#58378 - alexcrichton:incremental-lto, r=mic…
…haelwoerister

rustc: Implement incremental "fat" LTO

Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!

This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.

cc rust-lang#57968
cc rust-lang/cargo#6643

bors added a commit that referenced this pull request Feb 14, 2019

Auto merge of #58455 - Centril:rollup, r=Centril
Rollup of 7 pull requests

Successful merges:

 - #58309 (Add more profiler events)
 - #58347 (Closure bounds fixes)
 - #58365 (Add an option to print the status of incremental tasks / dep nodes after running them)
 - #58371 (Check user type annotations for range patterns.)
 - #58378 (rustc: Implement incremental "fat" LTO)
 - #58407 (specify "upper camel case" in style lint)
 - #58449 (Notify @topecongiro when the state of rustfmt has changed)

Failed merges:

r? @ghost

@bors bors merged commit e983b4f into rust-lang:master Feb 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment