-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Drop glue is always inlined into caller crate #64140
Comments
For a smaller reproduction of this:
|
I remember that @arielb1 was tuning |
Also share drop-glue when compiling with -Zshare-generics (i.e. at opt-level=0) This PR adds drop-glue to the set of monomorphizations that can be shared across crates via `-Zshare-generics`. This version of the PR might have detrimental effects on performance as it makes lots of stuff dependent on a single query results (`upstream_monomorphizations_for(def_id_of_drop_in_place)`). That should be fixable but let's do a perf run first. Potentially fixes issue #64140. (cc @alexcrichton) The changes here are related to @matthewjasper's #67332 but should be mostly orthogonal. r? @ghost
Also share drop-glue when compiling with -Zshare-generics (i.e. at opt-level=0) This PR adds drop-glue to the set of monomorphizations that can be shared across crates via `-Zshare-generics`. This version of the PR might have detrimental effects on performance as it makes lots of stuff dependent on a single query results (`upstream_monomorphizations_for(def_id_of_drop_in_place)`). That should be fixable but let's do a perf run first. Potentially fixes issue #64140. (cc @alexcrichton) The changes here are related to @matthewjasper's #67332 but should be mostly orthogonal. r? @ghost
Also share drop-glue when compiling with -Zshare-generics (i.e. at opt-level=0) This PR adds drop-glue to the set of monomorphizations that can be shared across crates via `-Zshare-generics`. This version of the PR might have detrimental effects on performance as it makes lots of stuff dependent on a single query results (`upstream_monomorphizations_for(def_id_of_drop_in_place)`). That should be fixable but let's do a perf run first. Potentially fixes issue #64140. (cc @alexcrichton) The changes here are related to @matthewjasper's #67332 but should be mostly orthogonal. r? @ghost
It seems like #68414 might help fixing this but is not sufficient on its own because |
This seems like a duplicate of #38827 |
Closing in favor of #38827, I agree this is a duplicate. |
I was investigating the compile time of a crate recently and came across a surprising aspect of the compiler. It looks like the drop glue, or rather the code necessary to drop a type, is inlined unconditionally into the caller crate, even if there are no generics in play.
This program:
generates a whopping 15 thousand lines of LLVM IR. Now
Command
certainly is a large type and I think it's fine that its drop glue is that big, but this is a concrete type and every single crate which usesCommand
is generating this 15 thousand lines of IR.At least in debug mode we shouldn't be doing this for concrete types, but rather the destructor of
Command
should be compiled into the standard library and then crates which use it should link against this precompiled copy. I would go as far as to argue that this should almost always happen and only when instructed otherwise should the compiler inline destructors across crates (same as for all other methods).cc @michaelwoerister, do you know if this was a deliberate decision, and is this perhaps something that's relatively easily fixed or something that would be much more intrusive to experiment with?
The text was updated successfully, but these errors were encountered: