From: "H. Peter Anvin" <hpa@zytor.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Glauber de Oliveira Costa <gcosta@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: Create clflush() inline, remove hardcoded wbinvd
Date: Sun, 22 Jul 2007 13:02:17 -0700 [thread overview]
Message-ID: <46A3B7C9.2050503@zytor.com> (raw)
In-Reply-To: <20070722195532.GA1432@one.firstfloor.org>
Andi Kleen wrote:
> On Sun, Jul 22, 2007 at 11:05:24AM -0700, H. Peter Anvin wrote:
>> Andi Kleen wrote:
>>>> The main reason is that everyone seems to invoke it either incorrectly
>>> Where is it incorrect?
>> Using "r" or "m" (as opposed as "+m") gives gcc the wrong dependency
>> information, and it could, at least in theory, cause memory references
>> to be moved around it -- especially when using "r".
>
> That doesn't sound correct. Taking the address should be like an escaping
> pointer and equivalent to read/write and effectively disable optimizations
> on this memory.
It might be in the existing gcc for all I know, but there is no explicit
guarantee to that effect. Remember that inline assembly is really
nothing but the guts of gcc exposed to the programmer, and that the gcc
people are very blunt about not wanting to muck with the former to suit
the latter. This means that there are a lot of things that may
accidentally work in one version of gcc which breaks in another.
There are two documented ways to tell gcc that you're mucking with
memory, and those are "m" constraints ("m" read, "=m" write, "+m"
read/write) and "memory" clobbers; the latter which affects all memory.
-hpa
next prev parent reply other threads:[~2007-07-22 20:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 22:55 [PATCH] Use wbinvd() macro instead of raw inline assembly in .c files Glauber de Oliveira Costa
2007-07-20 11:43 ` Andi Kleen
2007-07-20 17:22 ` H. Peter Anvin
2007-07-21 7:32 ` Muli Ben-Yehuda
2007-07-20 21:19 ` [PATCH] x86: Create clflush() inline, remove hardcoded wbinvd H. Peter Anvin
2007-07-20 21:27 ` Andi Kleen
2007-07-20 21:33 ` H. Peter Anvin
2007-07-22 9:18 ` Andi Kleen
2007-07-22 18:05 ` H. Peter Anvin
2007-07-22 19:55 ` Andi Kleen
2007-07-22 20:02 ` H. Peter Anvin [this message]
2007-07-20 23:37 ` Glauber de Oliveira Costa
2007-07-20 23:43 ` H. Peter Anvin
2007-07-21 18:11 ` Muli Ben-Yehuda
2007-07-21 19:52 ` H. Peter Anvin
2007-07-21 20:16 ` Muli Ben-Yehuda
2007-07-21 20:18 ` H. Peter Anvin
2007-07-21 20:44 ` Muli Ben-Yehuda
2007-07-21 22:09 ` H. Peter Anvin
2007-07-21 22:24 ` H. Peter Anvin
2007-07-22 4:20 ` Muli Ben-Yehuda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46A3B7C9.2050503@zytor.com \
--to=hpa@zytor.com \
--cc=andi@firstfloor.org \
--cc=gcosta@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox