auto merge of #9032 : alexcrichton/rust/inline-repr, r=thestinger

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:
![screen shot 2013-09-06 at 10 32 15 pm](https://f.cloud.github.com/assets/64996/1100723/e5e8744c-177e-11e3-83fc-ddc5f18c60f9.png)

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.

src/libstd/unstable/raw.rs

@@ -49,6 +49,7 @@ pub trait Repr<T> {
     /// struct representation. This can be used to read/write different values
     /// for the struct. This is a safe method because by default it does not
     /// give write-access to the struct returned.
+    #[inline]
     fn repr(&self) -> T { unsafe { cast::transmute_copy(self) } }
 }