Flag the Repr::repr function with #[inline]

[alexcrichton]

This allows cross-crate inlining which is very good because this is called a
lot throughout libstd (even when libstd is inlined across crates).

In one of my projects, I have a test case with the following performance characteristics

commit	optimization level	runtime (seconds)
before	O2	22s
before	O3	107s
after	O2	13s
after	O3	12s

I'm a bit disturbed by the 107s runtime from O3 before this commit. The performance characteristics of this test involve doing an absurd amount of small operations. A huge portion of this is creating hashmaps which involves allocating vectors.

The worst portions of the profile are:

Which as you can see looks like some serious problems with inlining. I would expect the hash map methods to be high up in the profile, but the top 9 callers of cast::transmute_copy were Repr::repr's various monomorphized instances.

I wish there we a better way to detect things like this in the future, and it's unfortunate that this is required for performance in the first place. I suppose I'm not entirely sure why this is needed because all of the methods should have been generated in-crate (monomorphized versions of library functions), so they should have gotten inlined? It also could just be that by modifying LLVM's idea of the inline cost of this function it was able to inline it in many more locations.

[thestinger]

It's not an issue with LLVM. If you mark a function as #[inline] we emit the AST into the metadata and compile it again, so anything it calls in libstd is a cross-crate call.

[alexcrichton]

It seems weird though because wherever Repr::repr is compiled to, it should inline cast::transmute_copy into itself, right?

[thestinger]

There are no guarantees about inlining those, because there are undefined bitcasts from type_use.

[thestinger]

Can you replicate it with -Z no-monomorphic-collapse?

[alexcrichton]

I cannot replicate it with no-monomorphic-collapse, interesting. The runtime goes from 23s => 11s with that flag.

[thestinger]

Yep, so it's just from undefined behaviour in our IR.

[alexcrichton]

There was talk of removing that part of the compiler, right?

[thestinger]

Yes, but it hasn't happened. The mergefunc pass hits an assert on the code produced by rustc when trying a build with it enabled.