[cfe-dev] atomic intrinsics

[Sebastian Redl]

On 06.10.2010 15:40, Howard Hinnant wrote:
> On Oct 6, 2010, at 9:34 AM, Sebastian Redl wrote:
>
>    
>> On 06.10.2010 02:26, Howard Hinnant wrote:
>>      
>>> On Oct 5, 2010, at 8:16 PM, Eric Christopher wrote:
>>>
>>>        
>>>> How about something like this:
>>>>
>>>> __atomic_load_seq_cst(__obj)
>>>>
>>>> that is processed by the front end into the llvm IR intrinsic (unless it has special knowledge) and then either emitted by the backend as a call to that function or inlined as atomic code if the backend knows how to do that.  That way the compiler can make the choice, but we also don't get people using the "intrinsics" in a non-portable way thinking that it's the actual api, and just use the API - and the front end knows what to do.
>>>>
>>>>          
>>> <nod>   Thanks Eric.  I should state right up front that I'm fine with this direction.  But it appears to me to need much more support from the front end (which is why I didn't propose it).  If we go this direction, there are no optional intrinsics for the front end.  The front end has to implement essentially everything specified in<atomic>.
>>>
>>>        
>> Why isn't automatic fallback in case of an unsupported intrinsic for a
>> particular size possible in this case?
>>      
> In the current design (http://libcxx.llvm.org/atomic_design.html) the library asks the question of whether an intrinsic exists or not, as they are optional.  Thus in the eyes of the compiler writer (front and back ends), the fallback is automatic.  Not every intrinsic need be implemented.
>
> Eric is suggesting to move that branch into the front end.  The compiler intrinsic exists in the front end, and the library calls it.  The front end asks the back end if it is supported and decides what to do.  I.e. to the library and to the back end, fallback is automatic, because the front end is now doing the decision making.
>    
Right, I mixed up Eric's suggestion and the suggestion about 
distinguishing intrinsic support by size instead of type.

Sebastian