This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Add pause intrinsic
On Wed, May 25, 2011 at 7:19 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, May 25, 2011 at 9:43 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 05/25/2011 04:32 PM, H.J. Lu wrote:
>>> On Wed, May 25, 2011 at 8:27 AM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Wed, May 25, 2011 at 5:20 PM, Michael Matz <matz@suse.de> wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, 25 May 2011, Richard Guenther wrote:
>>>>>
>>>>>>>> asm volatile ("" : : : "memory") in fact will work as a full memory
>>>>>>>> barrier
>>>>>>>
>>>>>>> How? ?You surely need MFENCE or somesuch, unless all you care about is
>>>>>>> a compiler barrier. ?That's what I think needs to be clarified.
>>>>>>
>>>>>> Well, yes, I'm talking about the compiler memory barrier.
>>>>>
>>>>> Something that we conventionally call "optimization barrier" :) ?memory
>>>>> barrier has a fixed meaning which we shouldn't use in this case, it's
>>>>> confusing.
>>>>
>>>> Sure ;)
>>>>
>>>> And to keep the info in a suitable thread what I'd like to improve here
>>>> is to make us disambiguate memory loads/stores against asms that
>>>> have no memory outputs/inputs.
>>>>
>>>
>>> Please let me know how I should improve the document,
>>
>> "Compiler memory barrier" seems to be well-understood. ?I suggest
>>
>> +Generates the @code{pause} machine instruction with a compiler memory barrier.
>>
>> It's clear enough.
>>
>> Andrew.
>>
>
> I checked in this.
>
> Thanks.
>
>
> --
> H.J.
> ---
> 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.
Richard.