expose expect intrinsics + mark push slow path

[thestinger]

This marks the slow path in the Vec<T> push function, improviding
code generation by moving it out of fast paths. The push function is
inlined in countless locations and not all of them order these blocks
appropriately without a hint. This improves the performance of the
microbenchmark in #15177 by 15% when dirty page purging is disabled.

Exposing the i1 version of the intrinsic for bool would be useful, but
the quirks of Rust's code generation prevent it from becoming branch
metadata so it has been left out for now.

A more sophisticated approach could be taken in the future (#11092) but
this provides a useful optimization feature today.

[alexcrichton]

This seems odd to only expose these macros as part of the libcore prelude, as there's basically no other core functionality that's present in the libcore prelude and not in the std prelude. Note, however, std prelude changes require an RFC.

[thestinger]

@alexcrichton: It's a performance optimization. These are intended to be marked as #[experimental], and AFAIK adding a useful feature like an optimization behind that stability flag is fine without an RFC - the compiler doesn't understand that for macros right now, which isn't just a problem for these.

[alexcrichton]

Oh dear, sorry for being a little slow to get back to you on this, it seems to have fallen through the cracks in my inbox!

Our current policy on modifying the prelude is to require an RFC. The threshold for something going into the prelude is that it needs absolutely overwhelming evidence that it should be in the prelude. It's an unfortunate side effect that currently all macros are "in the prelude" by virtue of being a macro. (would it be possible for these to be a function?). Some examples in the past where we've required an RFC are:

• Add syntax extensions for lowercasing/uppercasing strings (Fixes #16607) #16636
• Add a matches!(expr, pattern) macro. #14685

[wycats]

This just seems like a limitation in stability markers. It doesn't seem like @thestinger is trying to create a new public API, but the current implementation doesn't offer a way to mark the new macro as unstable or internal.

It doesn't seem like that should block this performance improvement.

[thestinger]

It can't be a function because lower-expect is a function pass. The expect markers are gone by the time inlining starts.

[alexcrichton]

@wycats yes, it's not supposed to be a public API, but that's the way macros work right now. As-is we require an RFC to modify the prelude (which includes macros right now), and we have precedent for holding off small performance improvements such as this because of macros (see #17857 and #16204).

Yes, this is unfortunate, and it's not the state of affairs we'd like to have, but it's an unavoidable reality with today's macro system.

[thestinger]

I'll put these in an #[experimental] crate instead of the prelude then.