[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C3F6353.3090409@zytor.com>
Date: Thu, 15 Jul 2010 12:36:51 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
CC: Zachary Amsden <zamsden@...hat.com>,
Glauber Costa <glommer@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Avi Kivity <avi@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: fix ordering constraints on crX read/writes
On 07/15/2010 12:28 PM, Jeremy Fitzhardinge wrote:
> On 07/15/2010 11:54 AM, H. Peter Anvin wrote:
>> No, we haven't. You're misunderstanding what a "memory" clobber does.
>> A clobber affects the output side only, but doesn't inherently provide
>> ordering on the input side. Apparently this is implicit in "asm
>> volatile", which is a very important property.
>
> OK. It would be nice to get that confirmed.
>
The section in the docs (gcc 4.4.4 section 5.37) reads as:
If your assembler instructions access memory in an unpredictable
fashion, add `memory' to the list of clobbered registers. This will
cause GCC to not keep memory values cached in registers across the
assembler instruction and not optimize stores or loads to that memory.
You will also want to add the `volatile' keyword if the memory affected
is not listed in the inputs or outputs of the `asm', as the `memory'
clobber does not count as a side-effect of the `asm'. If you know how
large the accessed memory is, you can add it as input or output but if
this is not known, you should add `memory'.
This was clearer to me when I read it last evening, either because I was
tired and on an airplane ;) or because I read too much into it... it's
worth noting that an asm() in gcc is really nothing more than an
internal compiler event exposed to the user; the terms "output", "input"
and "clobber" have pretty specific meaning in compiler theory, and they
at least appear to be used that way.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists