Always inline arithmetic operators

[Mark-Simulacrum]

In release mode, this has no effect, as they're inlined anyway, but in
debug mode LLVM otherwise lowers these to a call instruction -- much
more expensive than the inlined version.

Fixes #12279

If we decide not to land this I think we should close #12279 as won't fix.

r? @alexcrichton

[Mark-Simulacrum]

@bors try

I want to try to run perf to make sure this doesn't regress compilation time

[bors]

⌛ Trying commit 363b20e with merge e300b3d1d935612cbd734b3683c726874af46838...

[bors]

☀️ Try build successful - checks-travis
Build commit: e300b3d1d935612cbd734b3683c726874af46838

[Mark-Simulacrum]

@rust-timer build e300b3d1d935612cbd734b3683c726874af46838

[rust-timer]

Success: Queued e300b3d1d935612cbd734b3683c726874af46838 with parent 166c49d, comparison URL.

[rust-timer]

Finished benchmarking try commit e300b3d1d935612cbd734b3683c726874af46838, comparison URL.

[Mark-Simulacrum]

Looks like no compile time changes (as hoped for).

[jonas-schievink]

IIUC this change only affects code that is generic over these operators, and there might not be much of that in the benchmarks. Perhaps the num crates would be a better benchmark?

[Mark-Simulacrum]

Perhaps. If @alexcrichton decides this is reasonable I'll collect perf before landing probably

[alexcrichton]

Can you add a comment somewhere indicating why they're inline(always) and then comment each location pointing to that comment? Additionally is the purpose here to improve the runtime performance of debug binaries? If so what sort of speedups is this yielding?

[Mark-Simulacrum]

I am unable to measure performance benefits, and since that's the main goal here I'm going to close this PR -- and the relevant issue.