From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25379 invoked by alias); 28 Oct 2011 11:06:38 -0000 Received: (qmail 25365 invoked by uid 22791); 28 Oct 2011 11:06:38 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Oct 2011 11:06:18 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9SB6IbI031285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Oct 2011 07:06:18 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p9SB6Hbi029954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2011 07:06:17 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p9SB6HEP014121; Fri, 28 Oct 2011 13:06:17 +0200 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p9SB6G9C014119; Fri, 28 Oct 2011 13:06:16 +0200 Date: Fri, 28 Oct 2011 11:29:00 -0000 From: Jakub Jelinek To: Richard Henderson Cc: gcc-patches@gcc.gnu.org, amacleod@redhat.com Subject: Re: [cxx-mem-model][PATCH 0/9] Convert i386 to new atomic optabs. Message-ID: <20111028110616.GS1052@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <1319774858-9181-1-git-send-email-rth@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1319774858-9181-1-git-send-email-rth@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 X-SW-Source: 2011-10/txt/msg02645.txt.bz2 On Thu, Oct 27, 2011 at 09:07:29PM -0700, Richard Henderson wrote: > Jakub, in the seventh patch, is there any good reason why OMP is > making the decision of whether or not to generate a compare-and-swap > loop? Why shouldn't we simply always generate the __sync_fetch_op > builtin and let optabs.c generate the compare-and-swap loop? It just wants a guarantee that the builtin will actually be implemented in hw. I guess if __sync_fetch_op (new/old) isn't supported but __sync_compare_and_swap_* is, we could just use the former and let optabs.c deal with that. But we have to handle the CAS case anyway for most of the operations that don't have a __sync_fetch_op defined (and for the cases where we e.g. VCE floating point data to integer of the same size for CAS). For ABI reasons we should keep using GOMP_{start,end}_atomic for the types that don't have CAS in hw, shouldn't replace it with some generic C++11 atomic helper in some library (libgcc or elsewhere?). BTW, I believe all #pragma omp atomic ops we want in the relaxed model or weaker, I think OpenMP only guarantees that the memory is modified or loaded atomically (that you don't see half of something and half of something else), there is nothing that requires ordering the atomic vs. any other memory location stores/loads. Jakub