Skip to content

Inline direct calls to transmute_copy in the frontend #15398

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
pcwalton opened this issue Jul 4, 2014 · 7 comments
Closed

Inline direct calls to transmute_copy in the frontend #15398

pcwalton opened this issue Jul 4, 2014 · 7 comments
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@pcwalton
Copy link
Contributor

pcwalton commented Jul 4, 2014

When we see a direct call to mem::transmute_copy, we should just inline it in the frontend. This has two important benefits, one obvious and one not-so-obvious: (1) it reduces compilation time; (2) it can sometimes avoid one memcpy by translating the destination in place if the argument is an rvalue.

@emberian emberian self-assigned this Mar 25, 2015
@emberian emberian removed their assignment Jan 5, 2016
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 21, 2017
@nox
Copy link
Contributor

nox commented Mar 31, 2018

Does this still need to be done? Did anyone investigate it? The issue is not currently very actionable.

Cc @rust-lang/compiler @rust-lang/wg-codegen @rust-lang/wg-compiler-performance

@oli-obk
Copy link
Contributor

oli-obk commented Mar 31, 2018

are there enough transmute_copy calls to actually make any difference? I agree that this issue needs some numbers or we should just close it until transmute_copy shows up in other perf discussions

@jonas-schievink jonas-schievink added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 12, 2020
@bjorn3
Copy link
Member

bjorn3 commented May 15, 2022

#91743 should cause transmute_copy to be inlined before codegen.

@workingjubilee
Copy link
Member

That PR was merged so I am closing this on the presumption that it is happening just fine now and that if we need followups on that PR it can be tracked in another issue.

@bjorn3
Copy link
Member

bjorn3 commented Jul 6, 2022

It doesn't get inlined. I think the body of transmute_copy is too big. https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=1bb23b8a0df94e2aef6ea204baf6237d

@bjorn3 bjorn3 reopened this Jul 6, 2022
@workingjubilee
Copy link
Member

Welp, my bad! Thank you for catching that, @bjorn3.

bors added a commit to rust-lang-ci/rust that referenced this issue Aug 7, 2023
…r=lnicola

Don't provide `generate_default_from_new` when impl self ty is missing

Also don't provide the assist when the `Default` trait can't be found.

Part of rust-lang#15398
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 21, 2023
…nicola

minor: Remove `unwrap` from `Remove dbg!`

Part of rust-lang#15398.
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 21, 2023
…rts, r=lnicola

minor : Deunwrap remove_unused_imports

rust-lang#15398 Subtask 3
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 21, 2023
…_return, r=Veykril

minor : Deunwrap convert_to_guarded_return

Closes subtask 12 of rust-lang#15398
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 21, 2023
…methods, r=Veykril

minor : Deunwrap generate_delegate_methods

rust-lang#15398 subtask 8
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 21, 2023
…=lnicola

minor : Deunwrap generate_derive

rust-lang#15398 subtask 1. Since the editing closure has arms, I did something *experimental* ( in this case just a clever term for bad code ) to bypass creating an `Option` but I am ready to change this.
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 18, 2023
…n_result, r=Veykril

minor : Deunwrap wrap_return_type_in_result

rust-lang#15398 subtask 7
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 18, 2023
…r=Veykril

minor : Deunwrap extract_function

rust-lang#15398 subtask 5.
@istankovic
Copy link
Contributor

With current nightly and debug mode I get this:

playground::foo: # @playground::foo
# %bb.0:
	subq	$24, %rsp
	movq	%rdi, 16(%rsp)
	movq	16(%rsp), %rax
	movq	%rax, 8(%rsp)
	leaq	8(%rsp), %rdi
	callq	*core::mem::transmute_copy@GOTPCREL(%rip)
	addq	$24, %rsp
	retq

while with release mode I get

playground::foo: # @playground::foo
# %bb.0:
	movq	%rdi, %rax
	retq

Unless the call should also be inlined in debug mode, I'd say this works as expected.

@oli-obk oli-obk closed this as completed Oct 24, 2023
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 13, 2023
…kril

minor : Deunwrap inline call

rust-lang#15398 subtask 4. There is still one instance of unwrap, which I found pretty hard to change.
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 13, 2023
…arms, r=Veykril

Deunwrap add_missing_match_arms

Last subtask of rust-lang#15398
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 13, 2023
…ock, r=Veykril

minor : Deunwrap convert_comment_block and desugar_doc_comment

Closes subtask 13 of rust-lang#15398 . I still don't know a more idiomatic way for the for loops I added, any suggestion would make me happy.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

9 participants