Consider inlining `Poll::map`, `Poll::map_ok` and `Poll::map_err`

[EFanZh]

I noticed that in one of my project, inlining Poll::map manually reduces some binary size, then I noticed Poll::map is not marked #[inline]. Since both Option::map and Result::map are marked #[inline], I wonder whether this is an oversight. I failed to reproduce the binary size reduction effect with an example code, but maybe the reason behind inlining Option::map and Result::map also applies to Poll::map? How about Poll::map_ok and Poll::map_err?

[saethlin]

That's surprising. Can you share your project?

[EFanZh]

@saethlin Unfortunately, it is a private project, I cannot share it.

[saethlin]

Ah okay. I find it suspicious that these functions aren't inlining already. Did you try building your project against a modified standard library with #[inline] added to those functions?

Do you still get a code size improvement from manual inlining if you compile with codegen-units = 1 and/or lto = "fat" in your release profile? The functions in question ought to already be eligible for inlining, but by default the release profile has multiple codegen units per crate, which can result in surprising failures to inline things.

How big are these functions once they are compiled in your crate? The third-party tool cargo-bloat can help out here, can you share the output of

cargo bloat --release -n 1000000 | grep ::map

(of course trimming that down a bit if there are type names in there you don't want to fully disclose)
If for whatever reason these functions end up looking big to LLVM after other things are inlined into them, that may explain what's going on here, and your manual inlining has effectively changed in what order LLVM considers inlining things.

[EFanZh]

@saethlin I have done some tests on my project, using nm to check for symbols:

• Using lto=thin, Poll::map does not get inlined;
• Using lto=fat, Poll::map gets inlined;
• Using lto=thin and build-std, add #[inline] to standard library source code, Poll::map gets inlined;

All configurations above are using codgen-units=1 and opt-level=z.

nm reports that each Poll::map is about 68 to 96 bytes.

[saethlin]

What about lto=thin and #[inline] added to the standard library code, but without using -Zbuild-std?

If that configuration gets these functions inlined I think this is worth doing because it unlocks additional useful optimizations for users, but if the optimization is gated behind -Zbuild-std it's a bit less certain if this is a win.

@nikic Do you or any other LLVM folks have insight into why #[inline] would be impactful here? Are we relying on the hint part of its behavior?

[EFanZh]

@saethlin: It seems that changing standard library source code only works with build-std. Do I need to compile a customized version of Rust in order to test it?

[saethlin]

That's what I do. It's a very slow workflow.