On Thu, May 26, 2011 at 3:53 PM, Andrew Haley <a...@redhat.com> wrote:
> On 05/26/2011 02:51 PM, Richard Guenther wrote:
>> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley <a...@redhat.com> wrote:
>>> On 05/26/2011 10:34 AM, Richard Guenther wrote:
>>>
>>>>> Index: doc/extend.texi
>>>>> ===================================================================
>>>>> --- doc/extend.texi (revision 174216)
>>>>> +++ doc/extend.texi (working copy)
>>>>> @@ -8699,7 +8699,8 @@ The following built-in function is alway
>>>>>
>>>>> @table @code
>>>>> @item void __builtin_ia32_pause (void)
>>>>> -Generates the @code{pause} machine instruction with full memory barrier.
>>>>> +Generates the @code{pause} machine instruction with a compiler memory
>>>>> +barrier.
>>>>> @end table
>>>>
>>>> This isn't true. It is _not_ a compiler memory barrier.
>>>
>>> Please elucidate. Please suggest alternative wording.
>>
>> +Generates the @code{pause} machine instruction.
>
> But that's missing the fact that it generates a compiler memory barrier,
> which is important. And if you think it's not a compiler memory barrier,
> please explain
>
> a. Why it's not a compiler memory barrier,
It is not a compiler memory barrier because it is a builtin function call
which is never assumed to be a barrier for local automatic storage
that does not have its address taken.
> b. What you'd call it.
Not a compiler memory barrier ;)
To make it a compiler memory barrier you have to "expand" the
builtin already in the frontend and present the middle-end with
__asm__ ("...." : : : "memory"). That will serve as a compiler
memory barrier also covering local non-address taken storage
(global and practically most of address-taken local storage
is covered by a builtin function call already).
Richard.
>
> Andrew.
>
