2018-04-12 13:47:38 +00:00
|
|
|
#![stable(feature = "core_hint", since = "1.27.0")]
|
|
|
|
|
|
|
|
//! Hints to compiler that affects how code should be emitted or optimized.
|
|
|
|
|
2019-04-15 02:23:21 +00:00
|
|
|
use crate::intrinsics;
|
2018-04-12 13:47:38 +00:00
|
|
|
|
|
|
|
/// Informs the compiler that this point in the code is not reachable, enabling
|
|
|
|
/// further optimizations.
|
|
|
|
///
|
|
|
|
/// # Safety
|
|
|
|
///
|
|
|
|
/// Reaching this function is completely *undefined behavior* (UB). In
|
|
|
|
/// particular, the compiler assumes that all UB must never happen, and
|
|
|
|
/// therefore will eliminate all branches that reach to a call to
|
|
|
|
/// `unreachable_unchecked()`.
|
|
|
|
///
|
2018-11-27 02:59:49 +00:00
|
|
|
/// Like all instances of UB, if this assumption turns out to be wrong, i.e., the
|
2018-04-12 13:47:38 +00:00
|
|
|
/// `unreachable_unchecked()` call is actually reachable among all possible
|
|
|
|
/// control flow, the compiler will apply the wrong optimization strategy, and
|
|
|
|
/// may sometimes even corrupt seemingly unrelated code, causing
|
|
|
|
/// difficult-to-debug problems.
|
|
|
|
///
|
|
|
|
/// Use this function only when you can prove that the code will never call it.
|
2019-04-05 17:42:09 +00:00
|
|
|
/// Otherwise, consider using the [`unreachable!`] macro, which does not allow
|
2019-04-05 03:05:33 +00:00
|
|
|
/// optimizations but will panic when executed.
|
2018-04-12 13:47:38 +00:00
|
|
|
///
|
2019-04-05 17:42:09 +00:00
|
|
|
/// [`unreachable!`]: ../macro.unreachable.html
|
2018-04-12 13:47:38 +00:00
|
|
|
///
|
|
|
|
/// # Example
|
|
|
|
///
|
|
|
|
/// ```
|
|
|
|
/// fn div_1(a: u32, b: u32) -> u32 {
|
|
|
|
/// use std::hint::unreachable_unchecked;
|
|
|
|
///
|
|
|
|
/// // `b.saturating_add(1)` is always positive (not zero),
|
2019-02-09 22:16:58 +00:00
|
|
|
/// // hence `checked_div` will never return `None`.
|
2018-04-12 13:47:38 +00:00
|
|
|
/// // Therefore, the else branch is unreachable.
|
|
|
|
/// a.checked_div(b.saturating_add(1))
|
|
|
|
/// .unwrap_or_else(|| unsafe { unreachable_unchecked() })
|
|
|
|
/// }
|
|
|
|
///
|
|
|
|
/// assert_eq!(div_1(7, 0), 7);
|
|
|
|
/// assert_eq!(div_1(9, 1), 4);
|
2020-03-27 21:43:28 +00:00
|
|
|
/// assert_eq!(div_1(11, u32::MAX), 0);
|
2018-04-12 13:47:38 +00:00
|
|
|
/// ```
|
|
|
|
#[inline]
|
|
|
|
#[stable(feature = "unreachable", since = "1.27.0")]
|
|
|
|
pub unsafe fn unreachable_unchecked() -> ! {
|
2020-06-21 22:54:46 +00:00
|
|
|
// SAFETY: the safety contract for `intrinsics::unreachable` must
|
|
|
|
// be upheld by the caller.
|
|
|
|
unsafe { intrinsics::unreachable() }
|
2018-04-12 13:47:38 +00:00
|
|
|
}
|
2018-12-19 21:43:29 +00:00
|
|
|
|
2019-09-17 10:09:07 +00:00
|
|
|
/// Emits a machine instruction hinting to the processor that it is running in busy-wait
|
|
|
|
/// spin-loop ("spin lock").
|
2018-12-19 21:43:29 +00:00
|
|
|
///
|
2019-09-17 10:09:07 +00:00
|
|
|
/// For a discussion of different locking strategies and their trade-offs, see
|
|
|
|
/// [`core::sync::atomic::spin_loop_hint`].
|
2019-04-03 08:54:07 +00:00
|
|
|
///
|
|
|
|
/// **Note**: On platforms that do not support receiving spin-loop hints this function does not
|
|
|
|
/// do anything at all.
|
|
|
|
///
|
2019-09-18 10:31:34 +00:00
|
|
|
/// [`core::sync::atomic::spin_loop_hint`]: ../sync/atomic/fn.spin_loop_hint.html
|
2018-12-19 21:43:29 +00:00
|
|
|
#[inline]
|
|
|
|
#[unstable(feature = "renamed_spin_loop", issue = "55002")]
|
|
|
|
pub fn spin_loop() {
|
2019-12-07 04:18:12 +00:00
|
|
|
#[cfg(all(any(target_arch = "x86", target_arch = "x86_64"), target_feature = "sse2"))]
|
|
|
|
{
|
|
|
|
#[cfg(target_arch = "x86")]
|
|
|
|
{
|
2020-04-23 21:21:53 +00:00
|
|
|
// SAFETY: the `cfg` attr ensures that we only execute this on x86 targets.
|
2019-03-16 17:07:58 +00:00
|
|
|
unsafe { crate::arch::x86::_mm_pause() };
|
|
|
|
}
|
|
|
|
|
2019-12-07 04:18:12 +00:00
|
|
|
#[cfg(target_arch = "x86_64")]
|
|
|
|
{
|
2020-04-23 21:21:53 +00:00
|
|
|
// SAFETY: the `cfg` attr ensures that we only execute this on x86_64 targets.
|
2019-03-16 17:07:58 +00:00
|
|
|
unsafe { crate::arch::x86_64::_mm_pause() };
|
|
|
|
}
|
2018-12-19 21:43:29 +00:00
|
|
|
}
|
|
|
|
|
2019-12-07 04:18:12 +00:00
|
|
|
#[cfg(any(target_arch = "aarch64", all(target_arch = "arm", target_feature = "v6")))]
|
|
|
|
{
|
|
|
|
#[cfg(target_arch = "aarch64")]
|
|
|
|
{
|
2020-04-23 21:21:53 +00:00
|
|
|
// SAFETY: the `cfg` attr ensures that we only execute this on aarch64 targets.
|
2019-03-16 17:07:58 +00:00
|
|
|
unsafe { crate::arch::aarch64::__yield() };
|
|
|
|
}
|
2019-12-07 04:18:12 +00:00
|
|
|
#[cfg(target_arch = "arm")]
|
|
|
|
{
|
2020-04-23 21:21:53 +00:00
|
|
|
// SAFETY: the `cfg` attr ensures that we only execute this on arm targets
|
|
|
|
// with support for the v6 feature.
|
2019-03-16 17:07:58 +00:00
|
|
|
unsafe { crate::arch::arm::__yield() };
|
|
|
|
}
|
2018-12-19 21:43:29 +00:00
|
|
|
}
|
|
|
|
}
|
Moves test::black_box to core::hint
This changes removes a cyclic dependency between the "test" and "libtest"
crates, where "libtest" depends on "test" for "black_box", but "test" depends on
"libtest" for everything else.
I've chosen the "hint" module because there seems to be enough consensus in the
discussion of RFC2360 that this module is where such an intrinsic would belong,
but this PR does not implement that RFC! (note: if that RFC ever gets merged,
the API, docs, etc. of this API will need to change).
For backwards compatibility reasons I've chosen to also keep the "test" feature
gate for these instead of adding a new feature gate. If we change the feature
gate, we'll potentially all benchmarks, and while that's something that we could
do, it seems unnecessary to do that now - if RFC2360 gets merged, we'll need to
do that anyways.
2019-03-21 08:15:52 +00:00
|
|
|
|
2019-07-23 09:30:13 +00:00
|
|
|
/// An identity function that *__hints__* to the compiler to be maximally pessimistic about what
|
|
|
|
/// `black_box` could do.
|
Moves test::black_box to core::hint
This changes removes a cyclic dependency between the "test" and "libtest"
crates, where "libtest" depends on "test" for "black_box", but "test" depends on
"libtest" for everything else.
I've chosen the "hint" module because there seems to be enough consensus in the
discussion of RFC2360 that this module is where such an intrinsic would belong,
but this PR does not implement that RFC! (note: if that RFC ever gets merged,
the API, docs, etc. of this API will need to change).
For backwards compatibility reasons I've chosen to also keep the "test" feature
gate for these instead of adding a new feature gate. If we change the feature
gate, we'll potentially all benchmarks, and while that's something that we could
do, it seems unnecessary to do that now - if RFC2360 gets merged, we'll need to
do that anyways.
2019-03-21 08:15:52 +00:00
|
|
|
///
|
2019-07-23 09:30:13 +00:00
|
|
|
/// [`std::convert::identity`]: https://doc.rust-lang.org/core/convert/fn.identity.html
|
|
|
|
///
|
|
|
|
/// Unlike [`std::convert::identity`], a Rust compiler is encouraged to assume that `black_box` can
|
|
|
|
/// use `x` in any possible valid way that Rust code is allowed to without introducing undefined
|
|
|
|
/// behavior in the calling code. This property makes `black_box` useful for writing code in which
|
|
|
|
/// certain optimizations are not desired, such as benchmarks.
|
|
|
|
///
|
|
|
|
/// Note however, that `black_box` is only (and can only be) provided on a "best-effort" basis. The
|
|
|
|
/// extent to which it can block optimisations may vary depending upon the platform and code-gen
|
|
|
|
/// backend used. Programs cannot rely on `black_box` for *correctness* in any way.
|
2019-03-26 15:14:32 +00:00
|
|
|
#[inline]
|
2019-07-27 12:06:49 +00:00
|
|
|
#[unstable(feature = "test", issue = "50297")]
|
2019-06-10 15:12:14 +00:00
|
|
|
#[allow(unreachable_code)] // this makes #[cfg] a bit easier below.
|
Moves test::black_box to core::hint
This changes removes a cyclic dependency between the "test" and "libtest"
crates, where "libtest" depends on "test" for "black_box", but "test" depends on
"libtest" for everything else.
I've chosen the "hint" module because there seems to be enough consensus in the
discussion of RFC2360 that this module is where such an intrinsic would belong,
but this PR does not implement that RFC! (note: if that RFC ever gets merged,
the API, docs, etc. of this API will need to change).
For backwards compatibility reasons I've chosen to also keep the "test" feature
gate for these instead of adding a new feature gate. If we change the feature
gate, we'll potentially all benchmarks, and while that's something that we could
do, it seems unnecessary to do that now - if RFC2360 gets merged, we'll need to
do that anyways.
2019-03-21 08:15:52 +00:00
|
|
|
pub fn black_box<T>(dummy: T) -> T {
|
2019-06-10 15:12:14 +00:00
|
|
|
// We need to "use" the argument in some way LLVM can't introspect, and on
|
|
|
|
// targets that support it we can typically leverage inline assembly to do
|
2019-11-27 03:19:54 +00:00
|
|
|
// this. LLVM's interpretation of inline assembly is that it's, well, a black
|
2019-06-10 15:12:14 +00:00
|
|
|
// box. This isn't the greatest implementation since it probably deoptimizes
|
|
|
|
// more than we want, but it's so far good enough.
|
2020-04-23 21:21:53 +00:00
|
|
|
|
|
|
|
// SAFETY: the inline assembly is a no-op.
|
2019-06-10 15:12:14 +00:00
|
|
|
unsafe {
|
2020-01-14 13:40:42 +00:00
|
|
|
llvm_asm!("" : : "r"(&dummy));
|
2020-03-20 14:03:11 +00:00
|
|
|
dummy
|
2019-06-10 15:12:14 +00:00
|
|
|
}
|
Moves test::black_box to core::hint
This changes removes a cyclic dependency between the "test" and "libtest"
crates, where "libtest" depends on "test" for "black_box", but "test" depends on
"libtest" for everything else.
I've chosen the "hint" module because there seems to be enough consensus in the
discussion of RFC2360 that this module is where such an intrinsic would belong,
but this PR does not implement that RFC! (note: if that RFC ever gets merged,
the API, docs, etc. of this API will need to change).
For backwards compatibility reasons I've chosen to also keep the "test" feature
gate for these instead of adding a new feature gate. If we change the feature
gate, we'll potentially all benchmarks, and while that's something that we could
do, it seems unnecessary to do that now - if RFC2360 gets merged, we'll need to
do that anyways.
2019-03-21 08:15:52 +00:00
|
|
|
}
|