From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7114 invoked by alias); 4 Jun 2013 22:58:37 -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 7103 invoked by uid 89); 4 Jun 2013 22:58:37 -0000 X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from nm17-vm0.bullet.mail.ne1.yahoo.com (HELO nm17-vm0.bullet.mail.ne1.yahoo.com) (98.138.91.58) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 04 Jun 2013 22:58:36 +0000 Received: from [98.138.90.52] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2013 22:58:34 -0000 Received: from [98.138.226.124] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2013 22:58:34 -0000 Received: from [127.0.0.1] by smtp203.mail.ne1.yahoo.com with NNFMP; 04 Jun 2013 22:58:34 -0000 X-Yahoo-SMTP: fQw2HLOswBAfNNAqnKVM7sze51rEPzp2JLIy X-Rocket-Received: from [192.168.1.45] (limegreensocks@207.118.20.56 with ) by smtp203.mail.ne1.yahoo.com with SMTP; 04 Jun 2013 15:58:34 -0700 PDT Message-ID: <51AE7119.5090000@yahoo.com> Date: Tue, 04 Jun 2013 22:58:00 -0000 From: dw User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "gcc-help@gcc.gnu.org" Subject: Question about __builtin_ia32_mfence and memory barriers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00026.txt.bz2 The discussion below assumes 64bit code on an i386 processor. My understanding is that the way to do a memory barrier in gcc is: asm ("" ::: "memory"); This creates a ReadWriteBarrier, but no processor fence. To create a processor fence, you could do something like __builtin_ia32_mfence(); This will generate an mfence instruction, but (assembly code inspection suggests) no memory barrier. I thought about just putting one after the other: asm ("" ::: "memory"); __builtin_ia32_mfence(); And this leads to my questions: 1) Am I right that __builtin_ia32_mfence() does not generate a memory barrier? 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). 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? I expect this would always work: asm ("mfence" ::: "memory"); But I would rather use the builtins if possible. dw