Move test::black_box to std and stabilize it

[SimonSapin]

The test crate is not stable, and I’m not aware of plans to stabilize it soon. It’s probably better to spend some time experimenting on crates.io using harness = false in Cargo.toml (see rust-lang/cargo#2305).

I’ve extracted the test crate to eventually publish it separately and am removing usage of unstable features one by one. One of them is asm, used in:

/// A function that is opaque to the optimizer, to allow benchmarks to
/// pretend to use outputs to assist in avoiding dead-code
/// elimination.
///
/// This function is a no-op, and does not even read from `dummy`.
#[cfg(not(all(target_os = "nacl", target_arch = "le32")))]
pub fn black_box<T>(dummy: T) -> T {
    // we need to "use" the argument in some way LLVM can't
    // introspect.
    unsafe { asm!("" : : "r"(&dummy)) }
    dummy
}
#[cfg(all(target_os = "nacl", target_arch = "le32"))]
#[inline(never)]
pub fn black_box<T>(dummy: T) -> T {
    dummy
}

It’s an important part of benchmarking. Since asm! is not stable and also unlikely to be stable soon, I’d like to have black_box stabilized in std, as a building block for external test and benchmarking harnesses.

I’m not sure what module it would go into. Maybe std::time?

[sfackler]

std::mem might make more sense as a location, but this seems like a reasonable thing to do regardless.

[BurntSushi]

I like the idea too, especially if it lets folks experiment with benchmarking in an external crate. std::mem sounds betterish than std::time I think.

Is the documentation of black_box presented here something we can guarantee? What happens on nacl?

[huonw]

Is the documentation of black_box presented here something we can guarantee?

Probably not. E.g. a quick scan of the LLVM inline-asm docs implies it doesn't seem to say that it won't ever do any optimisations.

What happens on nacl?

I imagine black_box has absolutely no effect. I guess something like the following might work better (at some cost), although it will likely fail with LTO.

#[inline(never)]
fn not_cross_crate(x: *mut u8) {}

pub fn black_box<T>(dummy: T) -> T {
    not_cross_crate(&dummy as *const _ as *mut u8);
    dummy
}

[alexcrichton]

I don't think that we should stabilize black_box as it's currently "just a hack that appears to work". We don't really have any guarantees on behalf of LLVM nor do we really know what it does, it just emperically seems to not optimize things away. A solution like @huonw mentioned of a non-cross-crate function (e.g. something that forces codegen) would unfortunately have runtime overhead (which in theory this doesn't).

[SimonSapin]

Should we file an issue on LLVM about them providing some kind of black box with this guarantee? Between benchmark and timing attacks it’s not like we’re the only ones dealing with this problem.

[alexcrichton]

Perhaps, yeah, but it may not be too productive to do so without clearly figuring out what we want to actually do here. For example:

• Do we just want the value to not be optimized away?
• Do we want to prevent constant propagation?
• Do we want LLVM to think this isn't a constant even though it is?
• Are there other optimizations we want to prevent from happening? (we probably can't just say "don't optimize this value")

[cesarb]

The point of black_box is to behave as an "optimization barrier" for a variable. It should do two things:

• On entry to black_box, it should force the computation of its argument. The optimizer has to assume black_box depends on its argument and anything it might possibly point to;
• On exit from black_box, it should assume nothing about its return value. The optimizer has to assume black_box might have produced its return value from thin air. In particular, even if the argument to black_box was &T, the optimizer has to assume black_box might have returned a different &T, pointing to different contents.

Since it's a compiler barrier, a good place to look is the Linux kernel. What we want is a mixture of barrier_data and OPTIMIZER_HIDE_VAR. That is, what we want is the equivalent of the following inline assembly statement in GCC's syntax (Rust's syntax is slightly different):

__asm__ __volatile__ ("" : "=r" (var) : "0" (var) : "memory")

This statement produces no assembly (and the input and output registers are the same), but the optimizer is forced to assume:

• This statement should not be reordered with other statements, even if they seem to be unrelated;
• This statement might depend unpredictably on the input variable, and whatever it points to;
• This statement might return a different unpredictable value for the input variable, or if allowed (in case of &mut T or similar) might unpredictably modify whatever it points to.

[abonander]

It's not a no-op, and probably a naive idea, but would copying the value with ptr::read_volatile() and/or ptr::write_volatile() have the intended effect?

It definitely prevented the elision of memset() for zeroing a buffer on-drop in this case, though I used it to read the first byte in the buffer instead of the Vec object on-stack.

I would expect reading/rewriting the first byte of the value on-stack to be safe and of negligible cost while inducing the desired effect. It can be a no-op for ZSTs since they don't have any state to make assumptions of.

Addendum: this seems to produce the desired effect of preventing elision of memset(), even without #[inline(never)]: https://is.gd/T6Vbb4

Version that covers ZSTs, branch is optimized out: https://is.gd/ApKyY7

[bluss]

@abonander Just for exploration and for future reference, the read_volatile thing is not enough.

playpen link

use std::ptr;

fn main() {
    let buf = (Vec::<u8>::with_capacity(128), Vec::<u8>::with_capacity(64));

    black_box(buf);
}

fn black_box<T>(val: T) -> T {
    let _ = unsafe { ptr::read_volatile(&val as *const T as *const u8) };
    val
}

The allocation of the second vector will be optimized out, so it's using detailed information that only the first element of the tuple is needed. Using test::black_box, none of the vecs are optimized out, like we want.

[abonander]

@bluss Copying the whole value, however, does prevent the elision of the second allocation: https://is.gd/6Oc0xR

This also doesn't need to be special-cased. However, because it does force a copy of the full value it can be slow for larger types.

[bluss]

@abonander Thanks, that does work well so far

[hdevalence]

Standardizing a black_box function with the behaviour @cesarb described would be very useful in a bunch of different contexts beyond just benchmarking, and it's much smaller than, say, stabilizing inline asm.