On Fri, Mar 18, 2016 at 7:30 AM, Craig, Ben via cfe-commits < cfe-commits@lists.llvm.org> wrote:
> On 3/18/2016 1:50 AM, Joerg Sonnenberger via cfe-commits wrote: > >> On Thu, Mar 17, 2016 at 05:56:17PM +0000, JF Bastien via cfe-commits >> wrote: >> >>> C++ atomics are explicitly designed to avoid problems with touching >>> adjacent bytes: if `atomic<T>` where `sizeof(T) == 1` requires a 4-byte >>> `cmpxchg` then it's up to the frontend to make sure `sizeof<atomic<T>> >>> >= 4` >>> (or something equivalent such as making it non-lock-free). >>> >> That's not completely relevant for the code at hand. At least the >> __sync_* builtins only ever required appropiate alignment of the base >> type, not necessarily extra alignment to avoid padding for stupid >> codegen. I also believe that access to extra data is completely harmless >> for all but one use case. If you are directly accessing memory mapped >> devices using compiler atomics, you should really know what you are >> doing. That's about the only case where it matters. >> > volatile atomic is different from straight atomic, and should be handled accordingly by the target backend. Some architectures support byte granularity memory protection. Accessing > unsolicited bytes can cause a trap on those architectures. > > I think it makes sense for atomic<char> and Atomic<char> to get turned > into the 4 byte __atomic intrinsics. Those 4 byte __atomic intrinsics can > then get lowered to efficient inlined code. If someone has a regular char, > and they use the __atomic or __sync intrinsics directly, I'm fine with that > going to a lib call. The lib call can then either use the global lock > shard, or access extra data, depending on what is reasonable for that > platform. That all sounds like something the frontend has to decide on based on what the target is.
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits