rjmccall added a comment. In D79279#2168533 <https://reviews.llvm.org/D79279#2168533>, @jfb wrote:
> 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. I can see the usefulness of this operation, but it seems like a odd semantic mismatch for what is basically just a memcpy where one of the pointers happens to have `_Atomic` type, like you're shoe-horning it into this builtin just to avoid declaring a different one. 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
