Enable ThinLTO with incremental compilation. #53673

michaelwoerister · Aug 24, 2018

This is an updated version of #52309. This PR allows rustc to use (local) ThinLTO and incremental compilation at the same time. In theory this should allow for getting compile-time improvements for small changes while keeping the runtime performance of the generated code roughly the same as when compiling non-incrementally.

The difference to #52309 is that this version also caches the pre-LTO version of LLVM bitcode. This allows for another layer of caching:

if the module itself has changed, we have to re-codegen and re-optimize.
if the module itself has not changed, but a module it imported from during ThinLTO has, we don't need to re-codegen and don't need to re-run the first optimization phase. Only the second (i.e. ThinLTO-) optimization phase is re-run.
if neither the module itself nor any of its imports have changed then we can re-use the final, post-ThinLTO version of the module. (We might have to load its pre-ThinLTO version though so it's available for other modules to import from)

michaelwoerister · Aug 24, 2018

@bors try

bors · Aug 24, 2018

⌛️ Trying commit ee14d4a with merge 2d7e52f...

rust-highfive · Aug 24, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.


[00:04:40] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:40] tidy error: /checkout/src/librustc_codegen_llvm/back/lto.rs: missing trailing newline
[00:04:40] tidy error: /checkout/src/librustc_codegen_llvm/back/write.rs:2485: line longer than 100 chars
[00:04:42] Dependencies not on the whitelist:
[00:04:42] * memmap 
[00:04:42] some tidy checks failed
[00:04:42] 
[00:04:42] 
[00:04:42] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:42] 
[00:04:42] 
[00:04:42] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:42] Build completed unsuccessfully in 0:00:50
[00:04:42] Build completed unsuccessfully in 0:00:50
[00:04:42] make: *** [tidy] Error 1
[00:04:42] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:2f141b3c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:05342ea2:start=1535123775571971018,finish=1535123775580007110,duration=8036092
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1744e32a
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:07b14e58
travis_time:start:07b14e58
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0212adc5
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

kennytm · Aug 24, 2018

@bors try

bors · Aug 24, 2018

⌛️ Trying commit 1d0f3fd with merge 937c465...

rust-highfive · Aug 24, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:05:23] * memmap 
[00:05:23] some tidy checks failed
[00:05:23] 
[00:05:23] 
[00:05:23] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:05:23] 
[00:05:23] 
[00:05:23] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:05:23] Build completed unsuccessfully in 0:00:50
[00:05:23] Build completed unsuccessfully in 0:00:50
[00:05:23] make: *** [tidy] Error 1
[00:05:23] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:00a20dae
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:3453066c:start=1535127707846023606,finish=1535127707855087437,duration=9063831
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:2db993c0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:09be6192
travis_time:start:09be6192
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:01198ad8
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

alexcrichton · Aug 24, 2018

alexcrichton reviewed Aug 24, 2018

View changes

alexcrichton · Aug 24, 2018

src/librustc_codegen_llvm/base.rs

+        Err(e) => {
+            let msg = format!("Error while trying to load ThinLTO import data \
+                               for incremental compilation: {}", e);
+            sess.fatal(&msg)


Should this perhaps fall back on returning a new ThinLTOImports instance? It seems like if a previous compiler is ctrl-c'd at just the right time it could poison future compilers to return this error message

Yes, good catch.

alexcrichton · Aug 24, 2018

src/librustc_codegen_llvm/back/write.rs

@@ -983,6 +1006,9 @@ pub fn start_async_codegen(tcx: TyCtxt,
        allocator_config.emit_bc_compressed = true;
    }

+    modules_config.emit_pre_thin_lto_bc =
+        need_pre_thin_lto_bitcode_for_incr_comp(sess);


Should this be swapped with save_temps above so -C save-temps always emits it?

foo.pre-thin-lto.bc should actually be exactly the same as foo.thin-lto-input.bc, so I didn't really make an effort to add it to the save-temps output. Do you think it's worth the trouble?

I see what you mean now. Yes, it should be swapped so we don't overwrite the value.

alexcrichton · Aug 24, 2018

src/librustc_codegen_llvm/back/write.rs

+            execute_copy_from_cache_work_item(cgcx, work_item, timeline)
+        }
+        work_item @ WorkItem::LTO(_) => {
+            execute_lto_work_item(cgcx, work_item, timeline)


It looks like each of these methods takes the bound work_item but quickly unwraps it, could instead they be bound in this match and the value passed in here?

(ping on this comment)

alexcrichton · Aug 24, 2018

src/librustc_codegen_llvm/back/lto.rs

+                len: module.data().len(),
+            });
+            serialized.push(module);
+            module_names.push(name);


This looks the same as the loop above, so could chain be used to process both in one go? The modules_to_optimize local variable looks like it can be hoisted above the loop too perhaps?

alexcrichton · Aug 24, 2018

src/librustc_codegen_llvm/back/lto.rs

+            // the cache instead of having been recompiled...
+            let current_imports = ThinLTOImports::from_thin_lto_data(data);
+
+            // ... so we load this additional information from the previous


I'm not sure I'm following what's going on here. Aren't all CGUs loaded into the ThinLTOData instance? Is this perhaps an older comment?

AFAIK when we redo ThinLTO we have to unconditionally load the ThinLTO buffer for all CGUs coming inas input, so I can't quite figure out where some would be missing, but you can likely enlighten me!

alexcrichton · Aug 24, 2018

src/librustc_codegen_llvm/back/lto.rs

+    pub fn save_to_file(&self, path: &Path) -> io::Result<()> {
+        use std::io::Write;
+        let file = File::create(path)?;
+        let mut writer = io::BufWriter::new(file);


For this and load_from_file below I'd imagine that these maps are pretty small (on the order of CGUs, not symbols) which probably means that we can reasonable hold the entire contents of this serialized file in memory. In that case it's probably much faster to read/write the file in one go (and do all other operations in memory)

alexcrichton · Aug 24, 2018

src/librustc_codegen_llvm/base.rs

+    No,
+    PreThinLto,
+    PostThinLto,
+    PostThinLtoButImportedFrom,


I'm slightly confused by this enum variant, but I think this is the same confusion that I had before perhaps?

If any CGU is either "no" reusable or pre-thin-lto, I think that means that all CGUs need to be loaded for the ThinLTO data collection stage.

In thinking about this as well, I think this function below may not work in general? I think we can only determine CGU post-thin-lto CGU reuse after the ThinLTO data is created, right? Put another way, I think the possible reuse states are:

Everything is green, nothing has changed.

All modified CGUs need to be re-codegen'd

Afterwards, ThinLTOData is created, using the cached ThinLTO buffers for unmodified CGUs and freshly created buffers for re-codegen'd CGUs.

Now there's a graph of CGU to CGUs-imported, as well as whether each CGU is red/green (green for cached, red for just codegen'd)

Any red CGU is re-thin-LTO'd.

Any green CGU which imports from a red CGU is re-thin-LTO'd

Here, before we create the ThinLTOData, I don't think we can determine that a green CGU only imports from other green CGUs? LLVM seems like it could do fancy things such as:

Let's have three CGUs, A, B, and C.

A/B are green and C is red

Previously, A imported from B and not C

Afterwards, though, A ends up importing from both B and C (for whatever reason)

I think that this classification below would mean that A is "as green as can be" but it actually needs to be re-thin-LTO'd?

I may also just be lost with the classification of names here...

alexcrichton · Aug 24, 2018

src/librustc_codegen_llvm/base.rs

+                });
+                true
+            }
+            CguReUsable::PostThinLtoButImportedFrom => {


I suppose to elaborate on my comment above, the way I expected this to work these two latter states wouldn't be possible. It seems like don't really need to handle the case that literally nothing changed as it's not so important. In that case we can assume something changed which means that everything will either be codegen'd or sent as a pre-thin-lto module to the backend. After the synchronization point we'd then make another decision about CGU reuse and such.

bors · Aug 24, 2018

☀️ Test successful - status-travis
State: approved= try=True

alexcrichton · Aug 24, 2018

@rust-timer build 937c465

rust-timer · Aug 24, 2018

Success: Queued 937c465 with parent 57e13ba, comparison URL.

michaelwoerister · Aug 24, 2018

Yes, I can see one case where your A/B/C example would be handled sub-optimally: A references functions in both B and C, but in session 1 ThinLTO classifies no exported functions in C (and called from A) as potentially inlineable. Therefore the import data will show no edge from A to C. Then, in session 2, C is changed and now some function there has become small enough to be elegible for inlining. The algorithm in the PR would re-translate C (because it changed) but it would take the cached version of A since it has no edge to C. It would therefore not be able to inline functions from C into A although that might be possible now.

There are a couple of factors that somewhat lessen the negative effect:

If there is any potentially inlinable function in C that is called from A then an edge from A to C will exist and all functions in C will be covered because A will be included in the LTO phase.
If there is a function in C that is explicitly marked with #[inline] then changing that will invalidate A completely (as well as C) and both will be part of the LTO phase again.

That being said, deferring the classification to until after the index is built would solve the problem reliably (and is probably more in line with how the linker-plugin works). Unless I'm overlooking something, it shouldn't be too hard to implement it this way fortunately :) Good catch!

michaelwoerister · Aug 29, 2018

OK, so the perf results (which don't contain the proposed changes yet but should be kind of valid anyway) look better than last time:

Some cases profit a lot from incr. comp. (e.g. webrender, encoding, crates.io). The patched incremental: println case compiles 4-6 times faster than a non-incremental build. Many of the other cases are still twice as fast. If the runtime performance of the generated code is acceptable, that would be pretty good! Some crates though just hate incr. comp. it seems (yes, I'm looking at you style-servo).

michaelwoerister · Aug 31, 2018

@alexcrichton, I just pushed a commit that implements the algorithm as suggested by you. The code actually got simpler :) Let's see how it performs.

@bors try

bors · Aug 31, 2018

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

git checkout incr-thinlto-2000 (switch to your branch)
git fetch upstream master (retrieve the latest master)
git rebase upstream/master -p (rebase on top of it)
Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
git push self incr-thinlto-2000 --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

warning: Cannot merge binary files: src/Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging src/librustc/session/mod.rs
Auto-merging src/librustc/session/config.rs
Auto-merging src/Cargo.lock
CONFLICT (content): Merge conflict in src/Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

michaelwoerister · Sep 1, 2018

Thanks for the review, @alexcrichton. I'll resolve the nits after the weekend. After this lands, we should start another "Help us test ..." thread on irlo to see what runtime performance really looks like. These days we can also do a try build of Firefox and see how it performs in the benchmarks :)

rust-highfive · Sep 3, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.


[00:05:05] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:05:05] tidy error: /checkout/src/librustc_codegen_llvm/back/lto.rs: missing trailing newline
[00:05:07] some tidy checks failed
[00:05:07] 
[00:05:07] 
[00:05:07] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:05:07] 
[00:05:07] 
[00:05:07] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:05:07] Build completed unsuccessfully in 0:00:49
[00:05:07] Build completed unsuccessfully in 0:00:49
[00:05:07] Makefile:79: recipe for target 'tidy' failed
[00:05:07] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:258e2f6c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:01193813:start=1535973493112354274,finish=1535973493119607817,duration=7253543
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0edefa18
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:18fd4121
travis_time:start:18fd4121
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:2dd13962
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

michaelwoerister · Sep 3, 2018

I think all nits should be addressed now. I added some info!() output that shows which CGUs are loaded from cache and which are re-compiled.

@bors r=alexcrichton

bors · Sep 3, 2018

📌 Commit 21d05f6 has been approved by alexcrichton

bors · Sep 3, 2018

⌛️ Testing commit 21d05f6 with merge ee73f80...

bors · Sep 3, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing ee73f80 to master...

alexcrichton · Sep 3, 2018

😲

ljedrz · Sep 3, 2018

What happened to the perf? Plenty of stuff turned very red, is this expected?

nnethercote · Sep 4, 2018

Indeed, this had a calamitous effect on compile times for incremental opt builds, and I don't understand how this was deemed acceptable prior to landing. I think it should be backed out ASAP.

sentry-cli-opt
        avg: 254.9%     min: -0.0%      max: 972.3%
cargo-opt
        avg: 180.3%     min: 0.1%       max: 662.0%
syn-opt
        avg: 174.1%?    min: -2.4%?     max: 646.3%?
regex-opt
        avg: 108.3%     min: 0.1%       max: 326.0%
clap-rs-opt
        avg: 87.4%      min: 0.1%       max: 313.8%
regression-31157-opt
        avg: 78.0%      min: -1.2%      max: 262.6%
crates.io-opt
        avg: 71.9%      min: -0.2%      max: 243.2%
tokio-webpush-simple-opt
        avg: 65.9%      min: -0.1%      max: 156.1%
webrender-opt
        avg: 53.7%      min: 0.0%       max: 152.2%
hyper-opt
        avg: 40.4%      min: -0.0%      max: 119.7%
piston-image-opt
        avg: 19.5%      min: 0.0%       max: 50.0%
issue-46449-opt
        avg: 21.5%      min: -0.1%      max: 42.0%
ripgrep-opt
        avg: 14.6%      min: 0.1%       max: 39.5%
encoding-opt
        avg: 8.3%       min: 0.0%       max: 23.6%
inflate-opt
        avg: 9.1%?      min: 0.4%?      max: 18.2%?
html5ever-opt
        avg: 5.6%       min: -0.0%      max: 16.9% 
deeply-nested-opt
        avg: 5.7%       min: -0.1%      max: 16.6%
futures-opt
        avg: 2.4%       min: -0.1%      max: 8.9%
ucd-opt
        avg: 1.4%       min: -0.1%      max: 3.7%
keccak-opt
        avg: 1.1%       min: -0.1%      max: 3.2%
helloworld-opt
        avg: 1.2%       min: 0.2%       max: 2.6%

michaelwoerister · Sep 4, 2018

Yes, the effects on compile times were expected. Let me explain what's going on here: This PR enables a new combination of compiler settings (ThinLTO + incremental compilation) that we've wanted to have for years and that, as per the existing rules, is now selected as the default when doing optimized, incremental builds. The old behavior (optimized, incremental builds without the additional ThinLTO pass) is still available when compiling with -Clto=no and it's performance should not be affected by the changes in here. In fact, if you look at the non-incremental opt benchmarks, performance has gone up quite a bit in some cases (regex -1.5%, cargo -3.2%, crates.io -4.1%).

Without ThinLTO, incremental opt builds produce much slower code. In many cases benchmarks performed 2-3 times worse because of reduced IPO opportunities. If that code is fast enough for your needs, great, but there was no way we could make incremental compilation the default for optimized builds in Cargo. With ThinLTO enabled this might change. Once this is part of a nightly compiler, we'll test what runtime performance of code produced this way looks like; if it's close enough to non-incremental builds, we can make incr. comp. the default for opt builds in Cargo, giving compile time reductions of 50-85% for small changes!

Note that Cargo still defaults to non-incremental compilation for opt builds, so none of this will be visible to end users yet.

nnethercote · Sep 4, 2018

Huh, ok.

In fact, if you look at the non-incremental opt benchmarks, performance has gone up quite a bit in some cases (regex -1.5%, cargo -3.2%, crates.io -4.1%).

If you look at the perf results for just this PR, there are no improvements. (The few green entries are almost certainly noise, belonging to benchmarks that have high variance.)

michaelwoerister · Sep 4, 2018

If you look at the perf results for just this PR, there are no improvements.

Yeah, I was wondering why I hadn't seen those improvements in the try builds before :) That makes more sense anyway.

But it looks like script-servo-opt and style-servo-opt failed...

alexcrichton · Sep 5, 2018

@michaelwoerister hm oh I also just realized, this didn't actually add any tests? Would it be possible to add a few incremental + optimized tests to exercise these code paths? (I don't think we can really test it works without a disassembly and brittle tests), but we can at least try to run it through the ringer!

michaelwoerister · Sep 6, 2018

The existing incremental tests will actually test some of this when optimize-tests = true is set in config.toml. All tests are then compiled with ThinLTO, so we at least see if we get strange linker errors. I actually had to track down a few of them.

I'll think about how to test this some more. Maybe expand codegen tests a little so they properly deal with multiple CGUs? Or a run-make test if everything else fails...

alexcrichton · Sep 6, 2018

Oh nevermind then, carry on! So long as something broke when implementing this sounds like it's being exercised which is all I would look for :)

eddyb · Sep 8, 2018

eddyb reviewed Sep 8, 2018

View changes

eddyb · Sep 8, 2018

src/librustc_codegen_llvm/llvm/ffi.rs

@@ -1622,6 +1626,11 @@ extern "C" {
        Data: &ThinLTOData,
        Module: &Module,
    ) -> bool;
+    pub fn LLVMRustGetThinLTOModuleImports(
+        Data: *const ThinLTOData,


This should be &ThinLTOData.

michaelwoerister · Sep 10, 2018

I do have a few ideas for 2 or 3 tests. I'll make a PR this week, if I get to it. It requires exposing the different caching levels to the test framework. That's a good idea anyway but it's not totally trivial because of that.

michaelwoerister changed the title ~~Incr thinlto 2000~~ Enable ThinLTO with incremental compilation. Aug 24, 2018

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from ee14d4a to 1d0f3fd Aug 24, 2018

bors added S-waiting-on-bors S-waiting-on-author and removed S-waiting-on-bors labels Aug 24, 2018

kennytm added S-waiting-on-review and removed S-waiting-on-author labels Aug 24, 2018

TimNN added S-waiting-on-author and removed S-waiting-on-review labels Aug 28, 2018

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from 1d0f3fd to 8fdf3e6 Aug 31, 2018

michaelwoerister added some commits Sep 3, 2018

Add memmap crate to tidy whitelist.

d554575

incr.ThinLTO: Do some cleanup and add some logging.

Loading status checks…

21d05f6

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from 737f1ef to 21d05f6 Sep 3, 2018

bors added S-waiting-on-bors and removed S-waiting-on-author labels Sep 3, 2018

bors merged commit 21d05f6 into rust-lang:master Sep 3, 2018
2 checks passed

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

homu Test successful
Details

alexcrichton referenced this pull request Sep 3, 2018
Closed
Make `Vec` derefing inlinable #52704

eddyb referenced this pull request Sep 8, 2018
Open
Tracking issue for MIR-only RLIBs #38913

michaelwoerister referenced this pull request Sep 25, 2018
Merged
incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds. #54557

michaelwoerister referenced this pull request Oct 22, 2018
Open
Tracking Issue for Incremental Compilation 2018 #47660
20 of 32 tasks complete

alexcrichton referenced this pull request Dec 18, 2018
Closed
Enable ThinLTO and incremental compilation #48996

rust-lang/rust

Join GitHub today

Enable ThinLTO with incremental compilation. #53673

Conversation

michaelwoerister commented Aug 24, 2018 • edited

This comment has been minimized.

michaelwoerister commented Aug 24, 2018

This comment has been minimized.

bors commented Aug 24, 2018

bors added a commit that referenced this pull request Aug 24, 2018

michaelwoerister changed the title Incr thinlto 2000 Enable ThinLTO with incremental compilation. Aug 24, 2018

This comment was marked as resolved.

rust-highfive commented Aug 24, 2018

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from ee14d4a to 1d0f3fd Aug 24, 2018

This comment has been minimized.

kennytm commented Aug 24, 2018 • edited

bors added S-waiting-on-bors S-waiting-on-author and removed S-waiting-on-bors labels Aug 24, 2018

kennytm added S-waiting-on-review and removed S-waiting-on-author labels Aug 24, 2018

This comment has been minimized.

bors commented Aug 24, 2018

bors added a commit that referenced this pull request Aug 24, 2018

This comment has been minimized.

rust-highfive commented Aug 24, 2018

alexcrichton reviewed Aug 24, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

bors commented Aug 24, 2018

This comment has been minimized.

alexcrichton commented Aug 24, 2018

This comment has been minimized.

rust-timer commented Aug 24, 2018

This comment has been minimized.

michaelwoerister commented Aug 24, 2018

TimNN added S-waiting-on-author and removed S-waiting-on-review labels Aug 28, 2018

This comment has been minimized.

michaelwoerister commented Aug 29, 2018

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from 1d0f3fd to 8fdf3e6 Aug 31, 2018

This comment has been minimized.

michaelwoerister commented Aug 31, 2018

This comment has been minimized.

bors commented Aug 31, 2018

michaelwoerister added some commits Aug 17, 2018

This comment has been minimized.

michaelwoerister commented Sep 1, 2018

This comment has been minimized.

rust-highfive commented Sep 3, 2018

michaelwoerister added some commits Sep 3, 2018

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from 737f1ef to 21d05f6 Sep 3, 2018

This comment has been minimized.

michaelwoerister commented Sep 3, 2018

This comment has been minimized.

bors commented Sep 3, 2018

bors added S-waiting-on-bors and removed S-waiting-on-author labels Sep 3, 2018

This comment has been minimized.

bors commented Sep 3, 2018

bors added a commit that referenced this pull request Sep 3, 2018

This comment has been minimized.

bors commented Sep 3, 2018

Hide details View details bors merged commit 21d05f6 into rust-lang:master Sep 3, 2018 2 checks passed

2 checks passed

This comment has been minimized.

alexcrichton commented Sep 3, 2018

alexcrichton referenced this pull request Sep 3, 2018

This comment has been minimized.

ljedrz commented Sep 3, 2018 • edited

This comment has been minimized.

nnethercote commented Sep 4, 2018

This comment has been minimized.

michaelwoerister commented Sep 4, 2018

michaelwoerister commented Aug 24, 2018 •

edited

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from `ee14d4a` to `1d0f3fd` Aug 24, 2018

kennytm commented Aug 24, 2018 •

edited

alexcrichton reviewed Aug 24, 2018

View changes

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from `1d0f3fd` to `8fdf3e6` Aug 31, 2018

michaelwoerister force-pushed the michaelwoerister:incr-thinlto-2000 branch from `737f1ef` to `21d05f6` Sep 3, 2018

bors merged commit `21d05f6` into rust-lang:master Sep 3, 2018
2 checks passed

ljedrz commented Sep 3, 2018 •

edited

eddyb reviewed Sep 8, 2018

View changes