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

[WIP] Make derive(Clone) memcpy on enum variants containing only Copy types #47867

Closed
wants to merge 8 commits into from

Conversation

Manishearth
Copy link
Member

@Manishearth Manishearth commented Jan 30, 2018

(not yet ready for review)

Builds on #47865

fixes #47796

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

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

@kennytm kennytm added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 30, 2018
@Manishearth
Copy link
Member Author

Fixed a codegen segfault, now it should be working (still need to thoroughly test)

While this should be doing the right thing codegen-wise, there's a soundness hole. Currently this makes us lose the typechecking of "when all type parameters are Clone, all fields must be Clone" which we get for free in the regular custom derive since it generates Clone::clone calls. I'll need to add a wf check that ensures that such tagged enums get checked correctly.

Also, I need to tighten up the rustc_nocopy_clone marker addition so that it only gets added for enums. There are other cleanups which eddyb wishes to make to this code which should land first.

@Manishearth
Copy link
Member Author

This seems to work now. Ready for testing on Gecko (cc @bholley).

Todo:

  • rebase over Cleanup the shim code #47865 which now contains more of the cleanup from here
  • add the wf check
  • get it to show the correct spans in the debuginfo
  • optionally make it so that dump-mir shows in-use shims
  • tighten the nocopy_clone marker

@bors
Copy link
Contributor

bors commented Jan 30, 2018

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

@bholley
Copy link
Contributor

bholley commented Jan 30, 2018

To test this, build mozilla-central with --disable-debug --enable-optimize --enable-release. Then run:

nm --print-size --size-sort --radix=d libxul.so | grep "..Clone"

@nikomatsakis
Copy link
Contributor

@Manishearth to be sure, this is ready for review?

@Manishearth
Copy link
Member Author

Nope. Though if you want to do a preliminary review go ahead, the main part of the task is done and these patches are unlikely to change aside from the libsyntax stuff (the librustc_mir stuff is done).

@Manishearth
Copy link
Member Author

@nikomatsakis #47865 does need review though. And if you do have time, a review of the MIR code here and the overall approach would be very helpful. eddyb's mostly reviewed #47865 already and has gone through most of the code here but he said he wanted you to look at it too.

@nikomatsakis
Copy link
Contributor

@Manishearth yep, I saw it's assigned to me, will get to it soon

@Manishearth
Copy link
Member Author

So when I did my compile I got a libgkrust.a that was 4 megabytes smaller, but libXUL was 200kb larger .

I tried to do the symbol thing, however with this change there's a slight wrinkle; the shim symbols don't get correctly named. There are a lot of symbols like __ZN4core5clone5Clone5clone17hcccb0e6168f0476aE.39477 that aren't present in the original, and I believe these are the Clone impls. Summing up all the symbols with Clone in them it's a 200kb win, but because the symbols get differently named there's no guarantee that grepping for Clone measures the same thing in both.

Still, this seems promising enough that I should continue pushing on it.

I need to figure out how to get symbols and debuginfo working correctly. I suspect I need to pass the correct Span down, currently we're just passing down the Span of Clone::clone.

Measurement info:

$ git cinnabar git2hg @
5454ed95c82a956009db2f4b04d008ec8753e61e

# for the "before" build
$ rustc -V
rustc 1.25.0-nightly (21882aad7 2018-01-28)

# for the "after" build
$ rustc -V
rustc 1.25.0-dev
$ g rev-parse @
63c3c9398a8e70e4dffbf0f1b3931fcfd7360f0d

@Manishearth
Copy link
Member Author

Trying it out on a separate minimal file, the __ZN4core5clone5Clone5clone17hcccb0e6168f0476aE.39477 things are indeed the symbols we're looking for. Now to figure out how to get the correct symbol name attached to them

@Manishearth
Copy link
Member Author

@bholley Testing on my Mac, this overall saves 110kb in clone impls, and 61kb in PropertyDeclarationBlock code. A total of 29 functions get optimized by this.

However, libxul did overall get 360kb larger. I was using a nightly to build the "before" version and have a build running to get the "before" version with a minimal diff (i.e. just with and without my changes to rust) and should have results on that soonish.

@Manishearth
Copy link
Member Author

Manishearth commented Jan 31, 2018

On m-c rev 7b46ef2ae1412b15ed45e7d2367ca491344729f7 , on Linux, comparing this PR (ff517a) vs its base,

  • Patches reduced PropertyDeclaration clone impls by 67kb
  • Patches reduced total clone impls by 114kb
  • Patches caused libXUL size increase by 360kb (again, unsure why)

@bholley
Copy link
Contributor

bholley commented Jan 31, 2018

As mentioned on IRC: when you're measuring libxul, I hope you're using |size| rather than |du|?
Unless you strip debugging symbols, |du| will give you meaningless results.

bors added a commit that referenced this pull request Feb 5, 2018
Cleanup the shim code

 - We now write directly to `RETURN_PLACE` instead of creating intermediates
 - `tuple_like_shim` takes an iterator (used by #47867)
 - `tuple_like_shim` no longer relies on it being the first thing to create blocks, and uses relative block indexing in a cleaner way (necessary for #47867)
 - All the shim builders take `dest, src` arguments instead of hardcoding RETURN_PLACE

r? @eddyb
@bors
Copy link
Contributor

bors commented Feb 5, 2018

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

@Manishearth Manishearth changed the title [WIP] Make derive(Clone) memcpy on enum variants containing Copy types [WIP] Make derive(Clone) memcpy on enum variants containing only Copy types Feb 5, 2018
@shepmaster
Copy link
Member

Ping from triage, @Manishearth ! We haven't heard from you in a week or so; will you be able to address the feedback to get this PR out of WIP state soon?

@Manishearth
Copy link
Member Author

This PR is currently waiting on #48063

@shepmaster shepmaster added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 9, 2018
@shepmaster shepmaster added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. labels Feb 17, 2018
@pietroalbini pietroalbini added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. labels Feb 26, 2018
@bors
Copy link
Contributor

bors commented Mar 15, 2018

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

@pietroalbini pietroalbini added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. labels Mar 20, 2018
@pietroalbini
Copy link
Member

@Manishearth #48063 was closed for inactivity, what do you want to do with this?

@Manishearth
Copy link
Member Author

close it for now. It is a decent codesize/perf improvement, however for some reason this improvement doesn't carry over to larger codebases so I'm wary of landing this as is.

@eddyb do you want to bring this over the finish line?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

derived Clone implementations for many-variant enums are unnecessarily large
8 participants