use available_externally linkage for cross-crate inlined functions

[spernsteiner]

Cross-crate inlining currently uses internal linkage for functions that have been inlined from other crates. This works fine if the rustc-inlined copy of the function actually gets LLVM-inlined at all of its call sites, but if that doesn't happen, then we end up with an extra copy of the function in the object code. Using LLVM's available_externally linkage allows LLVM to perform inlining, but prevents the extra object code from being generated.

cc #14527

[alexcrichton]

Seems cool! Do you know how this affects binary sizes in the distribution?

[spernsteiner]

Whoops, seems this is not such a good idea after all. The code size reduction is only about 0.2% on average, and there's a slight performance penalty.

Turns out LLVM likes to fiddle with calling conventions on internal functions to get better performance. Changing to available_externally linkage prevents it from doing so. LLVM also makes different inlining decisions based on the calling convention being used.

I think we still ought to do something like this in the future, but rustc would probably need to be a little bit more clever about choosing calling conventions. (Also, we would probably get more code size savings by focusing on monomorphizations and drop/visit glue instead of #[inline] functions, but that would be more complicated to implement.)

[thestinger]

@epdtry: This is a good idea. At -O0 and -O1, only always(inline) functions are inlined. The code would perform better if it called out to better optimized functions in the libraries. You don't need to worry about the calling convention, because we could just be using fastcc for Rust rather than the C calling convention - our ABI is way less stable than fastcc.