From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31245 invoked by alias); 4 Jun 2013 23:52:29 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 31236 invoked by uid 89); 4 Jun 2013 23:52:28 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com) (209.85.214.180) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 04 Jun 2013 23:52:27 +0000 Received: by mail-ob0-f180.google.com with SMTP id eh20so1484942obb.39 for ; Tue, 04 Jun 2013 16:52:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=D+4iHqy9Zf+YxSpSm2AIsBJysGb57D51QU2pOR5yyqo=; b=M7U4A7zqJ8HdlhKs4BbHMag/e9iUYux15ajwqLDgtbGr+tIw/na5RrVgCxHfIjJjs6 YZeUvRvMEL6u40dWWCpWXCWxiPpQt2vPjg5iFhhN3iXkUIrl3rlvS20rjn8Ke9LEdS5B hkH6o40b94RcB9kSYkzFfe261vMuWxvMAdlTuZo+vBYDCozWi3gd0NNaRUa38VGN3Cbd s9Caz9Jqfdz+dGcxlScq787PVZ7LDZ/udX7Yt+lMcH3zX4ihXNLLWR5N+1lV430xxebp xQy/k9CievyfB1trOZmxv0N3nXxI/iaErSr+nhA9JV/nl7w90HHcSnoT1ZOLdDYNcCYf I7Ew== MIME-Version: 1.0 X-Received: by 10.182.237.6 with SMTP id uy6mr13401291obc.31.1370389946169; Tue, 04 Jun 2013 16:52:26 -0700 (PDT) Received: by 10.60.50.68 with HTTP; Tue, 4 Jun 2013 16:52:26 -0700 (PDT) In-Reply-To: <51AE7119.5090000@yahoo.com> References: <51AE7119.5090000@yahoo.com> Date: Tue, 04 Jun 2013 23:52:00 -0000 Message-ID: Subject: Re: Question about __builtin_ia32_mfence and memory barriers From: Ian Lance Taylor To: dw Cc: "gcc-help@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmjg9zwH+VDogJgZqhXLvunt9VOwCFhIZ0edRhsJTfmKnidw/AZfJIqMIxk/jVrzfL0itfJjKgyXh8ztCRL9YsiKK66NJQoh+9Anx7IFRm+NoMaN6lK0tf6FJQacX0I2fRBSHPdc/EXDXdtSrHnTmnOEEdYrvfc0hqSP51znJwCOfE+f8w76Ex0xOFl6spEngs9sIeu X-SW-Source: 2013-06/txt/msg00027.txt.bz2 On Tue, Jun 4, 2013 at 3:58 PM, dw wrote: > > To create a > processor fence, you could do something like > > __builtin_ia32_mfence(); A better choice these days is __atomic_thread_fence(__ATOMIC_SEQ_CST) (or __atomic_signal_fence). > 1) Am I right that __builtin_ia32_mfence() does not generate a memory > barrier? That is correct: it does not prevent the compiler from moving loads and stores across the call to __builtin_ia32_mfence. > 1) Is this "two statement thing" guaranteed to be safe? Could the optimizer > re-order instructions moving code in between the two? (Yes, I realize that > the asm statement doesn't actually generate any output. But given my > understanding of how the compiler processes code, I believe the question is > still valid). It is probably safe, because why would the compiler put anything in there, but it is not absolutely guaranteed to be safe. > 2) If it is not guaranteed to be safe, what is the use of > __builtin_ia32_mfence()? What value is there in preventing the *processor* > from executing statements out of order if the *compiler* is just going to > move them around? __builtin_ia32_mfence exists to support the Intel documented _mm_mfence intrinsic. I'm not clear on whether _mm_mfence is meant to be a compiler memory barrier or not. If it is, then I think GCC has a bug in the way it is implemented. Please feel free to file a bug report at http://gcc.gnu.org/bugzilla/ , especially if you can come up with a case that fails. > I expect this would always work: > > asm ("mfence" ::: "memory"); > > But I would rather use the builtins if possible. Yes, you should use the builtins. The __atomic builtins, which work better and are portable across processors. Ian