black_box improvements

[Manishearth]

No description provided.

[Manishearth]

Also mention that it prevents outer code from "seeing" the inside optimization-wise -- values produced by black_box are from the optimizer's perspective no different from being random.

[kennytm]

barrier

[gnzlbg]

fixed :)

[kennytm]

Could you explain what's the difference between clobber and compiler_fence, and when to use which?

[gnzlbg]

@kennytm sorry! for some reason I wasn't following this so I did not receive any notifications.

Could you explain what's the difference between clobber and compiler_fence, and when to use which?

Maybe the implementation helps? https://gist.github.com/gnzlbg/92b00f4d5362b06e72b48f824604e64e

First, black_boxprevents "the result" of an expression from being optimized away by saying "at the point of black_box something will read this value and do something depending on it".

What clobber says is a bit different: "at the clobber something will read all memory in the heap and do something depending on it".

For the Vec example, under some conditions (irrelevant here) LLVM can prove that the Vec allocation is unnecessary and elide it. What black_box does is saying "something will use the allocation here so you can't elide it". Afterwards, we push to the vector in a loop, and then free the vector. LLVM can, under some conditions, prove that we write to memory but all reads to it can be elided so that those writes to memory are unnecessary. What clobber then does is preventing LLVM from eliding the writes because at the point of the clobber something reads all memory and does something depending on the value of all memory.

I don't know exactly how compiler_fence works internally or how it should be used, but it looks like it is intended to synchronize reads/writes across threads by preventing reorderings. Even if you prevent a reordering, if LLVM can prove that the value written by one thread is not read by any other thread, the write can be elided without reordering anything. So the use-case seems a bit different. Clobber is more like a single-threaded full-memory fence, while compiler_fence seems to be a finer-grained multi-threaded memory fence.

But as mentioned, I am not 100% sure about this.

[Manishearth]

I think the above explanation is worth including in the reference-level explanation section.

By the way, it's likely that rust-lang#2287 will be closed given that folks seem to prefer rust-lang#2318 (in the discussions with the team so far).

In that case, we should make mem::black_box and clobber into its own RFC

[gnzlbg]

@Manishearth there is also rust-lang#1484 open where @SimonSapin suggests doing exactly that. Maybe we should move them already into its own RFC and ask the folks over there to get involved.

[Manishearth]

works for me. Would you like to open the RFC? I can help if you need.

[gnzlbg]

I'll add it to my todo list, might get to it later today.

[bstrie]

I'd be willing to write up the RFC for this. Presumably not much has changed about the assumed API since this was filed?

[Manishearth]

Yeah.