builtin arithmetic ops should be inlined when used in a generic function

[thestinger]

The basic operations on the built-in types compile to inferior code in generic functions without --opt-level=2 for heuristic-based inlining. The library should define these operations in the same way to avoid a distinction as not inlining them only slows down compile-time and doesn't aid in debugging.

[alexcrichton]

Can you provide any concrete numbers, data, statistics, or examples to go along with this assertion?

[thestinger]

Outside of a generic function, a + b is a single operation. Inside of a generic function, it's a method call. I think we should ensure that it's the same in both places. This is a rare place where #[inline(always)] doesn't hurt debugging, and speeds up compile times. I didn't make it clear enough that this is what I meant.

[steveklabnik]

triage: as far as I can tell, the IR for a generic and specific a + b are different, and so nothing has changed here.

[arielb1]

Does not seem to be relevant for Rust 1.3+ - could you provide an example?

[arielb1]

Actually, this is talking about:

fn foo<T: Add>(t: T) { t + t }
fn main() { t(4u32); }

[jfager]

Triage: still produces slower code without -O (godbolt link).

[hanna-kruppe]

Triage: Still true. Smaller test program (no I/O or formatting): https://godbolt.org/g/B9t75L

[bluss]

Current impl is here; is it really just about using inline(always) here? Any drawbacks to that?

macro_rules! add_impl {
    ($($t:ty)*) => ($(
        #[stable(feature = "rust1", since = "1.0.0")]
        impl Add for $t {
            type Output = $t;

            #[inline]
            #[rustc_inherit_overflow_checks]
            fn add(self, other: $t) -> $t { self + other }
        }

        forward_ref_binop! { impl Add, add for $t, $t }
    )*)
}

[Mark-Simulacrum]

Performance of compile times and run times was gathered based on #62095 but no measureable difference whether inline(always) is applied or not could be determined, so I'm closing this issue.