From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19640 invoked by alias); 28 Oct 2011 14:59:10 -0000 Received: (qmail 19622 invoked by uid 22791); 28 Oct 2011 14:59:09 -0000 X-SWARE-Spam-Status: No, hits=-6.7 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 14:58:43 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9SEwg81008997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Oct 2011 10:58:43 -0400 Received: from anchor.twiddle.net (vpn-236-140.phx2.redhat.com [10.3.236.140]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p9SEwgYK026664; Fri, 28 Oct 2011 10:58:42 -0400 Message-ID: <4EAAC321.9000108@redhat.com> Date: Fri, 28 Oct 2011 15:25:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Jakub Jelinek CC: gcc-patches@gcc.gnu.org, amacleod@redhat.com Subject: Re: [cxx-mem-model][PATCH 0/9] Convert i386 to new atomic optabs. References: <1319774858-9181-1-git-send-email-rth@redhat.com> <20111028110616.GS1052@tyan-ft48-01.lab.bos.redhat.com> In-Reply-To: <20111028110616.GS1052@tyan-ft48-01.lab.bos.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg02672.txt.bz2 On 10/28/2011 04:06 AM, Jakub Jelinek wrote: > 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). I was just thinking that the data structure with the 6 optabs that we're exporting from optabs.c is somewhat over the top, when simply testing can_compare_and_swap_p is just about equivalent. On reflection, I think I'll revert that patch and try it with just that one test... > 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. ... possibly with switching to the new builtins in relaxed mode? r~