On 05/26/2011 03:29 PM, Richard Guenther wrote:
> On Thu, May 26, 2011 at 3:53 PM, Andrew Haley <[email protected]> wrote:
>> On 05/26/2011 02:51 PM, Richard Guenther wrote:
>>> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley <[email protected]> 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.
OK. How would you tell the difference between the kind of barrier
that it is and a real compiler memory barrier? If an auto does not
have its address taken, it isn't visible anyway.
>> b. What you'd call it.
>
> Not a compiler memory barrier ;)
I don't want to know what not to call it, though.
> 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).
Well, the fact that it's also a memory clobber has to be documented
somehow. If the present documentation is to be changed, it should
not be changed by deleting a vital piece of information.
Andrew.
