[cfe-dev] atomic intrinsics

Howard Hinnant hhinnant at apple.com
Wed Oct 6 12:57:14 PDT 2010


On Oct 6, 2010, at 3:54 PM, Eric Christopher wrote:

> 
> On Oct 6, 2010, at 12:12 PM, Howard Hinnant wrote:
> 
>> On Oct 6, 2010, at 2:54 PM, Eric Christopher wrote:
>> 
>>> 
>>> On Oct 6, 2010, at 11:52 AM, Howard Hinnant wrote:
>>> 
>>>> On Oct 6, 2010, at 2:49 PM, Eric Christopher wrote:
>>>> 
>>>>> 
>>>>> On Oct 6, 2010, at 9:19 AM, Howard Hinnant wrote:
>>>>> 
>>>>>> In the hopes of clarification, I've put three design descriptions up at:
>>>>>> 
>>>>>> http://libcxx.llvm.org/atomic_design.html
>>>>>> 
>>>>>> A and/or B is what Eric proposed.  C is what I've been working toward.  A is my preference.  But I can't implement A without buy-in from the front end team.  Heck, I can't actually implement any of them without said buy-in. :-)  I chose C originally because that was where I thought I could most likely get buy-in.
>>>>> 
>>>>> To be more specific for A:
>>>>> 
>>>>> The front end handles every intrinisic listed, and the library provides a default and unoptimized implementation. The back end will provide a better optimized implementation if it can, otherwise falling back to a call to the library function.
>>>> 
>>>> In the above sentence I presume "the library" refers to compiler_rt, otherwise the clang would be tied to libc++.
>>> 
>>> Either/or.  It depends on whether you want these intrinsics to be generally useful or tied to the implementation of <atomic>.
>> 
>> I think if we do a good job with this, other implementations will follow.  Therefore I recommend compiler-rt (similar to dealing with complex arithmetic, count leading zeros, etc.)
> 
> Sure :)
> 
> You get to write it either way ;)

Fine with me, that part's easy.  Someone else gets to write the lock-free assembly. :-)

-Howard





More information about the cfe-dev mailing list