[PATCH] D17950: Implement is_always_lock_free

[Craig, Ben via cfe-commits]

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