Skip to content
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: Prepare to enable ThinLTO by default #46382

Merged
merged 3 commits into from
Dec 3, 2017

Conversation

alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Nov 29, 2017

This commit almost enables ThinLTO and multiple codegen units in release mode by
default but is blocked on #46346 now before pulling the trigger.

@rust-highfive
Copy link
Collaborator

r? @arielb1

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

@alexcrichton
Copy link
Member Author

r? @michaelwoerister

cc @rust-lang/compiler

@sfackler
Copy link
Member

Is this a blocker? #46346

@alexcrichton
Copy link
Member Author

Are we sure that's related to ThinLTO? I've tested everything locally and wasn't able to reproduce myself.

@alexcrichton
Copy link
Member Author

Urgh it may very well be. I swear to god.

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 29, 2017
// summaries in the index, and we basically just only want to ensure that dead
// symbols are internalized. Otherwise everything that's already external
// linkage will stay as external, and internal will stay as internal.
std::set<GlobalValue::GUID> ExportedGUIDs;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use a std::unordered_set here.

@cuviper
Copy link
Member

cuviper commented Nov 30, 2017

I see that LLVMRustThinLTOAvailable gates on just LLVM_VERSION_GE(4, 0). How well are you expecting this to work when using an external LLVM-4.0?
(IOW, are there rust-lang/llvm patches that I definitely need here?)

@alexcrichton
Copy link
Member Author

@cuviper IIRC rust-lang/llvm@e45c75d is the main (and possibly only) ThinLTO related patch (although it fixes a preexisting bug).

In general though I lose track over time what patch was for what on our fork, although everything that matters is upstream in some form so it's just a matter of time until we update to get it.

@cuviper
Copy link
Member

cuviper commented Nov 30, 2017

Ok, thanks, we already grabbed that one. I'll look back over the branch again later myself. I do appreciate that everything is fixed upstream first!

@michaelwoerister
Copy link
Member

Awesome! Will review shortly. Am I reading this right, this is still blocked on #46346?

@alexcrichton
Copy link
Member Author

@michaelwoerister unfortunately yes :(

Copy link
Member

@michaelwoerister michaelwoerister left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR looks good to me. Let's hope it doesn't bit rot too much until #46346 is resolved.

Can you explain to me why you don't use addPreservedGUID anymore?

}

/// Returns whether ThinLTO is enabled for this compilation
/// compilation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compilation compilation

// First validate the symbol. If it doesn't look like anything we're
pub fn demangle(writer: &mut Write, mut s: &str, format: PrintFormat) -> io::Result<()> {
// During ThinLTO LLVM may import and rename internal symbols, so strip out
// those endings first as they're on of the last manglings applied to symbol
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on -> one

for (int i = 0; i < num_symbols; i++) {
addPreservedGUID(Ret->Index,
Ret->GUIDPreservedSymbols,
GlobalValue::getGUID(preserved_symbols[i]));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this too conservative before?

Previously we were too eagerly exporting almost all symbols used in ThinLTO
which can cause a whole host of problems downstream! This commit instead fixes
this error by aligning more closely with `lib/LTO/LTO.cpp` in LLVM's codebase
which is to only change the linkage of summaries which are computed as dead.

Closes rust-lang#46374
Helps to avoid hitting path limits on Windows
This commit prepares to enable ThinLTO and multiple codegen units in release
mode by default. We've still got a debuginfo bug or two to sort out before
actually turning it on by default.
@alexcrichton alexcrichton changed the title rustc: Enable ThinLTO by default rustc: Prepare to enable ThinLTO by default Nov 30, 2017
@alexcrichton
Copy link
Member Author

@michaelwoerister ok I've updated the listing of commits and addressed comments. The commits now to not enable ThinLTO by default but instead retain retain today's default. The repo is left in a state though to make it a one line change to turn ThinLTO on by default in the future.

To answer your question about GUIDPreservedSymbols though there's more info on #46374 but it boils down to two things:

  • In the first location where GUIDPreservedSymbols was used the logic of addPreservedGUID wasn't necessary. The same result is computed whether we call addPreservedGUID or not.
  • In the second location it was incorrect to call addPreservedGUID in the sense that it added the transitive closure of symbols to that set. That in turn caused ThinLTO exposes too many symbols #46374 where too many symbols were exported (aka all of them) rather than just the set we wanted. By avoiding addPreservedGUID and tweaking the definition of isExported this bug was fixed though.

@michaelwoerister
Copy link
Member

Thanks for the explanation!

@bors r+

@bors
Copy link
Contributor

bors commented Nov 30, 2017

📌 Commit 855f6d1 has been approved by michaelwoerister

@kennytm kennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 30, 2017
@bors
Copy link
Contributor

bors commented Dec 2, 2017

⌛ Testing commit 855f6d1 with merge 088f328...

bors added a commit that referenced this pull request Dec 2, 2017
rustc: Prepare to enable ThinLTO by default

This commit *almost* enables ThinLTO and multiple codegen units in release mode by
default but is blocked on #46346 now before pulling the trigger.
@bors
Copy link
Contributor

bors commented Dec 3, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing 088f328 to master...

@bors bors merged commit 855f6d1 into rust-lang:master Dec 3, 2017
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Dec 7, 2017
In rust-lang#46382 the logic around linkage preservation with ThinLTO ws tweaked but the
loop that registered all otherwise exported GUID values as "don't internalize
me please" was erroneously too conservative and only asking "external" linkage
items to not be internalized. Instead we actually want the inversion of that
condition, everything *without* "local" linkage to be internalized.

This commit updates the condition there, adds a test, and...

Closes rust-lang#46543
bors added a commit that referenced this pull request Dec 8, 2017
rustc: Further tweak linkage in ThinLTO

In #46382 the logic around linkage preservation with ThinLTO ws tweaked but the
loop that registered all otherwise exported GUID values as "don't internalize
me please" was erroneously too conservative and only asking "external" linkage
items to not be internalized. Instead we actually want the inversion of that
condition, everything *without* "local" linkage to be internalized.

This commit updates the condition there, adds a test, and...

Closes #46543
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants