From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-231004-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31009 invoked by alias); 23 Nov 2008 20:37:25 -0000
Received: (qmail 30830 invoked by uid 22791); 23 Nov 2008 20:37:24 -0000
X-Spam-Check-By: sourceware.org
Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.191)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 23 Nov 2008 20:36:42 +0000
Received: by fk-out-0910.google.com with SMTP id 19so2170054fkr.8         for <gcc-patches@gcc.gnu.org>; Sun, 23 Nov 2008 12:36:31 -0800 (PST)
Received: by 10.181.207.9 with SMTP id j9mr870627bkq.149.1227472590912;         Sun, 23 Nov 2008 12:36:30 -0800 (PST)
Received: from localhost.localdomain (ar15-6.dial-up.arnes.si [194.249.3.6])         by mx.google.com with ESMTPS id z10sm1268744fka.39.2008.11.23.12.36.27         (version=TLSv1/SSLv3 cipher=RC4-MD5);         Sun, 23 Nov 2008 12:36:28 -0800 (PST)
Message-ID: <4929BEBA.9070207@gmail.com>
Date: Sun, 23 Nov 2008 20:58:00 -0000
From: Uros Bizjak <ubizjak@gmail.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: GCC Patches <gcc-patches@gcc.gnu.org>
CC: "H.J. Lu" <hjl.tools@gmail.com>,   Ross Ridge <rridge@csclub.uwaterloo.ca>
Subject: Re:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2008-11/txt/msg01219.txt.bz2

Hello!

> H.J. Lu writes:
> >I am not sure how useful that is for 32bit since it will generate a
> >nop for most machines which do need mfence.
>
> I don't understand what you're saying.  Using "lock orb" should result
> in a memory fence on any IA-32 SMP system, old or new.  It's just a more
> heavyweight way of ordering loads and stores.
>
> The Linux kernel apparently takes the same approach, using either "lock
> addl" or "mfence" depending on whether SSE2 instructions are available
> at compile time.
>   

No, linux dynamically patches its code:

#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", 
X86_FEATURE_XMM2)
#define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", 
X86_FEATURE_XMM2)
#define wmb() alternative("lock; addl $0,0(%%esp)", "sfence", 
X86_FEATURE_XMM)

But anyway, gcc can't do that by itself.

Uros.