Inline direct calls to transmute_copy in the frontend

[pcwalton]

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.

[nox]

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]

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

[bjorn3]

#91743 should cause transmute_copy to be inlined before codegen.

[workingjubilee]

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]

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

[workingjubilee]

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

[istankovic]

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.