jfb added a comment. In D79279#2168479 <https://reviews.llvm.org/D79279#2168479>, @rjmccall wrote:
> Is there a need for an atomic memcpy at all? Why is it useful to allow this > operation to take on "atomic" semantics — which aren't actually atomic > because the loads and stores to elements are torn — with hardcoded memory > ordering and somewhat arbitrary rules about what the atomic size is? Hans lays out a rationale for usefulness in his paper, but what I've implemented is more useful: it's *unordered* so you can fence as you desire around it, yet it guarantees a minimum memory access size based on the pointer parameters. For example, copying an atomic `int` will be 4 byte operations which are single-copy-atomic, but the accesses from one `int` to the next aren't performed in any guaranteed order (or observable in any guaranteed order either). I talked about this with him a while ago but IIRC he wasn't sure about implementation among other things, so when you asked me to widen my original `volatile`-only `memcpy` to also do other qualifiers, I realized that it was a neat way to do atomic as well as other qualifiers. I've talked to a few SG1 folks about this, and I believe (for other reasons too) it's where the design will end up for Hans' paper. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79279/new/ https://reviews.llvm.org/D79279 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
