-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
3d31898
to
275dde3
Compare
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. |
This seems to work now. Ready for testing on Gecko (cc @bholley). Todo:
|
☔ The latest upstream changes (presumably #47870) made this pull request unmergeable. Please resolve the merge conflicts. |
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" |
0369c8a
to
63c3c93
Compare
@Manishearth to be sure, this is ready for review? |
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). |
@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. |
@Manishearth yep, I saw it's assigned to me, will get to it soon |
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 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:
|
Trying it out on a separate minimal file, the |
@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. |
On m-c rev 7b46ef2ae1412b15ed45e7d2367ca491344729f7 , on Linux, comparing this PR (ff517a) vs its base,
|
As mentioned on IRC: when you're measuring libxul, I hope you're using |size| rather than |du|? |
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
☔ The latest upstream changes (presumably #47865) made this pull request unmergeable. Please resolve the merge conflicts. |
ff5117a
to
96c3649
Compare
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? |
This PR is currently waiting on #48063 |
☔ The latest upstream changes (presumably #47630) made this pull request unmergeable. Please resolve the merge conflicts. |
@Manishearth #48063 was closed for inactivity, what do you want to do with this? |
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? |
(not yet ready for review)
Builds on #47865
fixes #47796