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.
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.
-- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation
Center, Inc. is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
