Does black_box expose it's address operands? Does it have a side effect dependant on its parameter?

[chorman0773]

In a recent T-opsem UCG Backlog Bonanza meeting, we closed #311 declaring that, from an opsem perspective, core::hint::black_box(x) was no different from core::convert::identity(x).
However, over on the Rust Community Discord, two questions came up that struck me as a reason to reopen a constrained version of that question, namely:

1. If the operand to black_box contains any pointer bytes, does black_box expose those pointers?
2. Does black_box perform a side effect dependent on it's parameter?

In my opinion, the answer to the first question should be "No", as there isn't a reason to make it do an expose. However, the second question is a litle more substantial. While this is not currently the case, IIRC there have been times in the past where black_box(CONST) or black_box(inlineable_pure_function()) have been elided by the compiler. This is strictly allowed, but undesireable. I'm also unsure if there is a reason not to make black_box perform a side effect (and the current implementation on rustc already expects this, by using an non-pure asm!() block that takes addr_of!(x)).

@rustbot label +S-pending-team-decision

Note: I do not believe that there is necessarily any design that needs to happen arround "how" black-box either exposes/doesn't-expose and how it has a side effect, so this should only need a T-opsem decision as to each of the individual questions. If this assesment is wrong, feel free to relabel as S-pending-design. This also doesn't have a currently existing, suitable A- label, but as I expect this to be a one-off issue (:ferrisClueless:), I do not believe there is a need to create one.

[bjorn3]

I think from a purely opsem perspective black_box should be side-effect free, but any reasonable compiler should still consider it to have a side-effect that depends on it's parameter whenever reasonable. It should still be valid for a compiler to optimize out black_box, but it should prefer not to.