From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94241 invoked by alias); 31 Jul 2017 15:50:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 94231 invoked by uid 89); 31 Jul 2017 15:50:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1193, hesitate X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 31 Jul 2017 15:50:13 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A303568FEE; Mon, 31 Jul 2017 15:50:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A303568FEE Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-116-95.phx2.redhat.com [10.3.116.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1DFE417DEC; Mon, 31 Jul 2017 15:50:12 +0000 (UTC) Subject: Re: [PATCH 1/2] x86,s390: add compiler memory barriers when expanding atomic_thread_fence (PR 80640) To: Alexander Monakov Cc: gcc-patches@gcc.gnu.org, Richard Henderson , Uros Bizjak References: <793d0ecb-7fbf-6670-c45b-9b1d436fc2fb@redhat.com> <499f27d4-7abc-a0a1-34af-2de2710058dc@redhat.com> From: Jeff Law Message-ID: <85f131c5-3ebd-0ed9-4bc1-78a9482c841c@redhat.com> Date: Mon, 31 Jul 2017 15:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg02037.txt.bz2 On 07/26/2017 12:13 PM, Alexander Monakov wrote: > On Wed, 26 Jul 2017, Jeff Law wrote: >> I'm not sure what you mean by extraneous compiler barriers -- isn't the >> worst case scenario here that the target emits them as well? So there >> would be an extraneous one in that case, but that ought to be a "don't >> care". > > Yes, exactly this. > >> In the middle end patch, do we need a barrier before the fence as well? >> The post-fence barrier prevents reordering the fence with anything which >> follows the fence. But do we have to also prevent reordering the fence >> with prior instructions with any of the memory models? This isn't my >> area of expertise, so if it's dumb question, don't hesitate to let me >> know :-) > > That depends on how pessimistic we want to be with respect to backend > getting it wrong. My expectation here is that if a backend emits non-empty > RTL, the produced sequence for the fence itself acts as a compiler memory > barrier. Perhaps. But do we really want to rely on that? EMitting a scheduling barrier prior to these atomics is virtually free. Jeff