Call to wrapping_add not inlined in debug mode

[dbdr]

For reasons outside my control, I would like to have the option to perform unchecked, wrapping arithmetic in debug mode with reasonable performance. Since + is checking for overflows, I thought that using wrapping_add would do the job, however a function like:

pub fn inc_opt(data: u64) -> u64 {
    u64::wrapping_add(data, 42)
}

gets compiled (in debug mode) to

0000000000005d50 <inc::inc_opt>:
    5d50:       push   %rax
    5d51:       mov    $0x2a,%esi
    5d56:       callq  5650 <core::num::<impl u64>::wrapping_add>
    5d5b:       mov    %rax,(%rsp)
    5d5f:       mov    (%rsp),%rax
    5d63:       pop    %rcx
    5d64:       retq   
    5d65:       nopw   %cs:0x0(%rax,%rax,1)
    5d6f:       nop

The call to wrapping_add does not get inlined, even though wrapping_add is marked #[inline] and is obviously short. I tried to the following patch:

diff --git a/src/libcore/num/mod.rs b/src/libcore/num/mod.rs
index a259e293b0c..6c2d3fc6d5a 100644
--- a/src/libcore/num/mod.rs
+++ b/src/libcore/num/mod.rs
@@ -1242,7 +1242,7 @@ $EndFeature, "
             #[rustc_const_stable(feature = "const_int_methods", since = "1.32.0")]
             #[must_use = "this returns the result of the operation, \
                           without modifying the original"]
-            #[inline]
+            #[inline(always)]
             pub const fn wrapping_add(self, rhs: Self) -> Self {
                 intrinsics::wrapping_add(self, rhs)
             }

However that did not seem to change the generated code (I'm new to hacking on rustc, so it's very possible I did not try it correctly).

Is there any hope in stable rust to be able to compile wrapping arithmetic expressions to a single instruction even in debug mode?

Is there a more general issue with inlining not being performed when it should?

[dbdr]

This old reddit comment by @solson is relevant to this issue, and mentioned that "i32::wrapped_add call doesn't get inlined because it's not #[inline(always)] - this could be added". However it seems to me that even adding it is not enough to force the inlining.

[tmiasko]

There are two separate implementations for signed and unsigned types. The code above is for the other one, which is why it didn't have intended effect.

Always inlining intrinsics wrappers like those seems like reasonable thing to do.

[dbdr]

@tmiasko you're absolutely right, I missed the int_impl / uint_impl distinction. I'm testing again after adding the other one. If that works I'll extend to the other similar cases with an intrinsic implementation and submit a PR.

[dbdr]

#[inline(always)] does work:

0000000000005f10 <inc::inc_opt>:
    5f10:       sub    $0x10,%rsp
    5f14:       add    $0x2a,%rdi
    5f18:       mov    %rdi,0x8(%rsp)
    5f1d:       mov    0x8(%rsp),%rax
    5f22:       mov    %rax,(%rsp)
    5f26:       mov    (%rsp),%rax
    5f2a:       add    $0x10,%rsp
    5f2e:       retq   
    5f2f:       nop

Preparing my first PR :)

[tmiasko]

Somewhat of a sidenote, the optimization level and debug information are
separate compilation options, so there are more possible combinations
than built-in profiles in cargo might suggest.

The line information enabled at debuginfo=1 is pretty well preserved even at
higher optimization levels. If you are more interested in actual debugging
experience, combining debuginfo=2 with opt-level=1 might still be acceptable.

There is also an interesting middle ground of debuginfo=2 with MIR
optimizations (-Z mir-opt-level >= 2), but without LLVM optimizations.
The inlining in question is performed in this case without any changes
to the standard library. This combination of flags is rarely used,
so there be dragons.

[dbdr]

Thanks for the information @tmiasko! In general these option can be useful, however in this (niche) situation I don't have control over the compilation options. However, I believe the change to libcore should be generally beneficial without drawbacks, so I opened the PR.

[Mark-Simulacrum]

This is "intentional" -- std and Rust code in general is going to be quite slow at -O0. As noted on the PR, just adding inline(always) isn't quite the right thing here, as it has other (averse) effects. Without knowing more about your specific use case, I can't really help more, but I would suggest that posting on users.rust-lang.org if you want further help achieving your goals would be the right way forward.