jfb added a comment. In D79279#2170095 <https://reviews.llvm.org/D79279#2170095>, @rjmccall wrote:
> I don't think any of these should allow _Atomic unless we're going to give it > some sort of consistent atomic semantics (which is hard to imagine being > useful), and I think you should just take an extra argument of the minimum > access width on all of them uniformly if you think that's important. > Builtins can have optional arguments. OK so: `__builtin_memcpy_overloaded` which overloads on `volatile`, `restrict`, `__unaligned`, and address spaces, but not on `_Atomic` qualifiers. Optionally, a 4th integer parameter can be provided to represent `element_size`. If provided, this becomes an unordered atomic memcpy with element size equal to or greater than the provided `element_size`. That value must be a power of two, and must be lock-free (what we call maximum atomic inline width in target info). If provided, then `__unaligned` is invalid, and `volatile` ought to be valid but is currently unsupported because IR can't do atomic+`volatile` memcpy (it would be useful, say for shared memory, but Patches Welcome). Do you think there should be any relationship at all between dst/src pointee type's size and `element_size`? i.e. if I copy `short*` using an element size of 1 byte, is that OK? It seems like larger element sizes is always OK, but smaller might be a programmer error? If that's what they wanted, they could have done `(char*)my_short`. Or is this trying to be too helpful? 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
