Using `&v` instead of `v` arg in `format!` does not inline, causing ~6% perf hit

[nyurik]

I tried this code:

pub fn func(i: i32) -> String {
    format!("{}", &i)
}

I expected &i to be inlined and be equivalent to format!("{}", i)

Instead, in my benchmarking tests I see about 6% performance hit, and assembly has a non-inlined function.

Relevant links

• Assembly comparison
• Benchmarking code
• A Clippy lint: A new lint to remove unneeded arg referencing in a format! rust-clippy#10851
• Stackoverflow question

Meta

rustc --version --verbose:

rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-unknown-linux-gnu
release: 1.69.0
LLVM version: 15.0.7

[Jules-Bertholet]

@rustbot label A-codegen I-slow

[nyurik]

cc: @m-ou-se because it might be related to all the great format-AST related work

[m-ou-se]

Right now, every argument to format_args!() turns into a Argument, which is basically a &dyn Display but a bit different:

rust/library/core/src/fmt/rt.rs

Lines 66 to 78 in 23f93a1

	/// This struct represents the generic "argument" which is taken by format_args!().
	/// It contains a function to format the given value. At compile time it is ensured that the
	/// function and the value have the correct types, and then this struct is used to canonicalize
	/// arguments to one type.
	///
	/// Argument is essentially an optimized partially applied formatting function,
	/// equivalent to `exists T.(&T, fn(&T, &mut Formatter<'_>) -> Result`.
	#[lang = "format_argument"]
	#[derive(Copy, Clone)]
	pub struct Argument<'a> {
	value: &'a Opaque,
	formatter: fn(&Opaque, &mut Formatter<'_>) -> Result,
	}

I don't expect llvm to be able to optimize that in any meaningful way.

So I don't think this is something we can immediately solve. Longer term, a new implementation could do this very differently and perhaps tackle this issue.

related to all the great format-AST related work

I don't think the AST is enough to tell if a & can be dropped, because for !Sized things, the & must stay.

Perhaps we can special case &identifier only, if we're sure that in that case there are no subtle edge cases where the & must stay. (But in that case it should maybe just be a warning (from clippy or rustc).)

[nyurik]

Thanks @m-ou-se for the explanation. I was hoping that while argument is represented as a &dyn Display-like structure, code generation and optimization would inline the fmt() call, removing the extra complexity.