[PATCH] D17950: Implement is_always_lock_free

[JF Bastien via cfe-commits]

On Fri, Mar 18, 2016 at 7:30 AM, Craig, Ben via cfe-commits <
cfe-commits at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160318/ca7b8994/attachment.html>