[PATCH] D17950: Implement is_always_lock_free

[Craig, Ben via cfe-commits]

On 3/18/2016 11:54 AM, JF Bastien wrote:
>
>     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.

A lot of it is a frontend decision.  What goes in the libcall feels an 
awful lot like the 386 vs 486 example that I hear a lot.  If I want one 
binary that can run on both a 386 (very limited atomic support) and a 
486 (a bit more atomic support), then I generate the binary such that it 
has library calls to atomic routines.  The library on the 386 uses the 
global lock shard, and the library on the 486 uses native instructions.  
The same kind of thing would apply for one byte atomics when only four 
byte atomics have hardware support.  The library call would use the lock 
shard as the default. If the platform doesn't have byte granularity 
memory protection a different, lockless implementation could be used 
that loads the surrounding four bytes instead and does all the masking.

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160318/d9633b31/attachment-0001.html>