There was an issue somewhere about potential implementations of
memcpy using vector instructions wanting to load memory out of bounds but I cannot find it. @briansmith ?
That's a second example about wanting to be able to read and modify memory that's out-of-bounds.
@gnzlbg do you mean https://github.com/rust-rfcs/unsafe-code-guidelines/issues/2 ?
yeah all of that is currently UB until someone gets the LLVM devs to allow it, I think
these inbounds assumptions are used pervasively in alias analysis, I would not want to risk violating them
Check out the Atomic integer issue.
Basically, it is being argued that smaller atomic integer types can be emulated on top of larger ones.
But that requires applying atomic memory operations for a larger type, which access memory out-of-bounds.
So maybe the answer here is that no, smaller atomic integer types cannot be emulated on top of larger ones.
that is, I think, indeed the answer, at least with LLVM as the backend
@RalfJ even with a different backend, to support this we would have to introduce memory operations that can read / write memory out-of-bounds (whether the reads / writes are atomic, volatile, or something else is irrelevant).
While at machine level emulating the atomics via CAS loop on a larger memory region is (just fine)™, it has to be done after LLVM (optimisation pipeline) gets it teeth to the code.
i.e. implementing this in assembly is fine and so is fine to do so in instruction selection legalisation, I think.
yeah, maybe you can even do that in LLVM's later lower-level IRs