When using a stdio based macro, e.g. println!(...) the assembly generated goes like so:
; ...
call qword ptr [rip + std::io::stdio::_print@GOTPCREL]
link to compiler explorer: Compiler Explorer
I would really love this to get inlined into the main() section.
Your Godbolt link is broken.
weird, should be fixed
when using -Cremark=all, we get a LLVM remark:
**note** **: <source>:2:5 inline (missed): _ZN3std2io5stdio6_print17ha3358eb27b9f8cbdE will not be inlined into _ZN7example4main17h6947cdf83b16969fE because its definition is unavailable**
Well, how do we get to std::io::stdio::_print (?) definition properly? 
Hm, have you tried it locally, or just on godbolt?
Can you elaborate on why?
Also, if you have requests like this, you probably want to enable LTO.
Yep, rust 1.73.0 compiles with the same warnings.
Can you elaborate on why?
Should I? I want stdio::print to be inlined into the main function, I really don't think its too much to ask for.
You probably want to enable LTO
Tried that, no effect whatsoever.
std::io::stdio::_print is a function, not a macro.
It is not generic and not marked #[inline], so it is not eligible for cross-crate inlining without LTO: https://github.com/rust-lang/rust/blob/master/library/std/src/io/stdio.rs#L1087-L1096
It will not make a measurable difference in the performance of the posted program. In general, inlining IO methods is not actually a good idea, as they will be used in multiple places and the cost of the IO is much higher than the cost of a call, so deduping the code is good.
Thus presumably you have some other motivation, and by elaborating that motivation we might be able to provide a more helpful answer.
This seems OK.
The ::print gets put into a register.
After the fact, calling println! directly seems to be just
call r14
But, when making a single println! statement this would be good to inline.
Will open up an issue about this, maybe.
Thank you, lads.